Jump to content

  • Log In with Google      Sign In   
  • Create Account


How can 2 threads have the same id?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 noatom   Members   -  Reputation: 781

Like
0Likes
Like

Posted 25 May 2014 - 04:07 PM

You can call ::get_id() to get the id of a thread, it is also possible to have two ids that are the same. And as far as I know ownership of threads is movable but not copyable, so how can two threads have the same id?



Sponsor:

#2 Andy Gainey   Members   -  Reputation: 1972

Like
1Likes
Like

Posted 25 May 2014 - 04:34 PM

I thought I had recently seen the answer to this; turns out, rip-off mentioned the answer in his reply to your earlier thread:

 

 

An initialized thread object represents an active thread of execution; Such a thread object is joinable, and has a unique thread id.

A default-constructed (non-initialized) thread object is not joinable, and its thread id is common for all non-joinable threads.

(emphasis added)



"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke

#3 samoth   Crossbones+   -  Reputation: 4628

Like
3Likes
Like

Posted 25 May 2014 - 05:00 PM

They can't.

 

The wording of the standard is, as usual, a contorted, unintellegible, total mess for something that is actually very easy. Hence your confusion.

 

A thread object can refer to an actual thread, or it may not. A thread object may exist before the actual thread is created and beyond its lifetime, and it may lose "ownership" when it is moved, etc etc. Also, an acutal thread can obviously exist without a thread object.

 

If you query a thread object for its ID, then it depends on whether  it corresponds to an actual thread. If it does, it returns that thread's ID (which is unique), otherwise it returns some bogus ID which is not a valid thread ID (since it doesn't correspond to a valid thread!). That bogus ID is (obviously) the same for all thread objects that don't correspond to an actual thread.


Edited by samoth, 25 May 2014 - 05:01 PM.


#4 noatom   Members   -  Reputation: 781

Like
0Likes
Like

Posted 26 May 2014 - 08:00 AM

thank you both for clearing that up.



#5 JohnnyCode   Members   -  Reputation: 230

Like
0Likes
Like

Posted 26 May 2014 - 08:49 AM

Try to compare that ID with the proccess ID you created it from, just for curiosity. Might be the missing magic value ? Ugly situation though :(, does that happen?!



#6 samoth   Crossbones+   -  Reputation: 4628

Like
2Likes
Like

Posted 26 May 2014 - 10:41 AM


Ugly situation though sad.png, does that happen?!

Actually this is not an ugly situation at all, but by design. The function get_id is declared to return a thread::id object, which means it must return one (a thread::id object is really just a mini-wrapper around a native_handle_type, which would e.g. be int32_t for Linux or void* for Windows, plus 3 or 4 convenience members like operator==).

It's the way functions work in C++. If you say that it returns something, say, an integer, then unless the function throws an exception, it has no choice but to actually return one.

 

But what do you return when there is no thread associated with the thread object? There is no meaningful value that you could return. So obviously, you return some default value, there's not much more you can do to it, but it's also not something that is nasty, it's just a concequence of the fact that you must return something.

Most probably that "magic value" will simply be zero, but the standard doesn't require that, it merely says that it's the same value for all non-joinable threads (this makes it identifiable, also it is a very practical constraint), and it's not a valid thread ID.

 

You can't do anything meaningful (other than compare it) with that ID, but that, too, is only normal. It doesn't make a lot of sense to query the ID of a thread object that doesn't correspond to a thread at all in the first place. However, since that function is declared, you are able to call it. No matter how nonsensical it may be, you can call this function, and it must work in a predictable, well-defined manner.

The way the standard is worded, it's guaranteed that you get something that is well-defined back in every case (not always useful, but always well-defined).


Edited by samoth, 26 May 2014 - 10:44 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS