I want a class to know what thread it's in and be able to tell when it's in a new thread. How would I do this? And is it the same on all platforms in C++?
I want a class to know what thread it's in and be able to tell when it's in a new thread. How would I do this? And is it the same on all platforms in C++?
On Windows there's GetCurrentThread() & GetCurrentThreadID(). On UNIX you'd use some equivalent pthreads functions.
Please gime some details what u want...
An object is never in a thread. A particular method is executing in a thread. If you want thread-affine objects, you need to capture the thread ID in the constructor (for example using boost::this_thread::id() from Boost.Thread 1.35), store it in a member, and assert that it's the same in every method.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
It lives on the stack of whatever thread it is being run in. But if you in some way or another get a reference (or pointer) to that object and pass it to another thread (let's call the current thread A, and the other thread B), then it still sits on Thread A's stack, but is being used in Thread B. So the object only belongs to a thread in the sense that the thread (may) own the memory where the object is stored, but the use of that object is by no means restricted to one thread (as defined by the C++ language).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I take it you mean for an object to exist in a thread - yeah, sure, but the point I made is still valid - you can pass objects from one thread to another in various ways.
Further the original post refers to wanting to know which thread currently is using/owning an object - I think this implies that objects ARE moved around between threads in the case the OP wants to work on.
And the transfer of objects from one thread to another is not that unusual - it's quite common to have a thread that produces objects, for another thread to "pick up" (get, retrieve or whatever you want to call it). For example, you could have a read thread that queues up packets of data read from a file, and another thread to process (calculate with the data or re-organize the content of it for example) the data that was read, and finally another thread to write the data to an output file.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Perhaps, but I don't think that's a very meaningful distinction. It's all a matter of semantics.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That's great, but if you have this knowledge, then it doesn't make sense for the object to find out the thread it's in.
I think of this in terms of references to the object. What you're calling "the object is in a thread" is "only this thread has references to the object" to me. The advantage of my terminology is apparent when this situation changes. If another thread gains a reference, my term is "these two threads have references". I can't think of a good way to change the other formulation.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law