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

This is a discussion on How can an object know what thread it's in? within the C++ Programming forums, part of the General Programming Boards category; I want a class to know what thread it's in and be able to tell when it's in a new ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    184

    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++?

  2. #2
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    On Windows there's GetCurrentThread() & GetCurrentThreadID(). On UNIX you'd use some equivalent pthreads functions.

  3. #3
    Registered User
    Join Date
    Mar 2008
    Posts
    5
    Please gime some details what u want...

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  5. #5
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by CornedBee View Post
    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;
        ....
    }

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by medievalelks View Post
    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
    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.

  7. #7
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by matsp View Post
    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?

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  9. #9
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by CornedBee View Post
    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.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by medievalelks View Post
    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
    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.

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  12. #12
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by matsp View Post
    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".

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by medievalelks View Post
    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
    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.

  14. #14
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by matsp View Post
    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.

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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Thread Prog in C language (seg fault)
    By kumars in forum C Programming
    Replies: 22
    Last Post: 10-09-2008, 02:17 PM
  2. synchronization object choosing
    By George2 in forum C# Programming
    Replies: 0
    Last Post: 03-22-2008, 05:33 AM
  3. API Thread HEADACHE
    By WaterNut in forum Windows Programming
    Replies: 11
    Last Post: 01-16-2007, 10:10 AM
  4. [code] Win32 Thread Object
    By Codeplug in forum Windows Programming
    Replies: 0
    Last Post: 06-03-2005, 04:55 PM
  5. A question about constructors...
    By Wolve in forum C++ Programming
    Replies: 9
    Last Post: 05-04-2005, 05:24 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21