How can an object know what thread it's in?

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.

Quote:

---

Originally Posted by CornedBee

An object is never in a thread. A particular method is executing in a thread.

---

Not sure what you mean. Where does "data" live?

Code:

---

void *consumer_thread(void *arg)
{
    SomeData data;
    ....
}

---

Quote:

---

Originally Posted by medievalelks

Not sure what you mean. Where does "data" live?

Code:

---

void *consumer_thread(void *arg)
{
    SomeData data;
    ....
}

---

---

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

Quote:

---

Originally Posted by matsp

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).

---

But by default, it's a thread-specific object until you programatically break that constraint. So indeed, it's possible for a thread to exist in a thread, no?

Perhaps, but I don't think that's a very meaningful distinction. It's all a matter of semantics.

Quote:

---

Originally Posted by CornedBee

Perhaps, but I don't think that's a very meaningful distinction. It's all a matter of semantics.

---

Why? No other thread can access that data (hence there's no need to lock access to it) unless you purposely break that encapsulation.

Quote:

---

Originally Posted by medievalelks

But by default, it's a thread-specific object until you programatically break that constraint. So indeed, it's possible for a thread to exist in a thread, no?

---

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

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.

Quote:

---

Originally Posted by matsp

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.

---

That's great, but my argument is not "objects always exist in one thread only", but merely a counter-example to the claim that "objects never exist in a thread".

Quote:

---

Originally Posted by medievalelks

That's great, but my argument is not "objects always exist in one thread only", but merely a counter-example to the claim that "objects never exist in a thread".

---

I'm not sure what you are trying to say - objects can exist in any scope, local or global, and be references from or created by other objects, etc, etc. Not all objects are local stack objects - this is the only object that I would say is implicitly "in a thread".

Like CornedBee says: using the term "one thread holds a reference to the object" is a much better term than "is in a thread".

--
Mats

Quote:

---

Originally Posted by matsp

I'm not sure what you are trying to say - objects can exist in any scope, local or global, and be references from or created by other objects, etc, etc. Not all objects are local stack objects - this is the only object that I would say is implicitly "in a thread".

---

That's all I was saying.

Quote:

---

Like CornedBee says: using the term "one thread holds a reference to the object" is a much better term than "is in a thread".

---

That's subjective. Each thread has it's own stack, and to me it seems more logical that the objects on it "exist in the thread".