[thread] Are thread ids unique during an applications life time?
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states: "An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#thread.th... Which sounds like thread ids are free to be re-used. Johan -- View this message in context: http://www.nabble.com/-thread--Are-thread-ids-unique-during-an-applications-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Johan Torp <johan.torp@gmail.com> writes:
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states:
"An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#thread.th...
Which sounds like thread ids are free to be re-used.
std::thread::id values may be reused by new threads. boost::thread::id values are not reused by new threads until the thread has terminated, and there is no boost::thread object or boost::thread::id objects referring to that thread (they are reference counted). Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Johan Torp:
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states:
"An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution."
http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#783
Peter Dimov-5 wrote:
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states:
"An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution."
http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#783
I also expect re-use will mean users have to re-implement "unique_thread_id" and some really difficult-to-fix bugs for people who do not think about it. OTOH, I see some value in that std::thread::id are the same as window's thread ids when you're debugging and post-mortem debugging. Since issue #783 is marked as ready, does it mean it is closed and the proposed text has been added to the standard? I was hoping re-use would be disallowed :/ Johan -- View this message in context: http://www.nabble.com/-thread--Are-thread-ids-unique-during-an-applications-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Johan Torp <johan.torp@gmail.com> writes:
Peter Dimov-5 wrote:
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states:
"An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution."
http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#783
I also expect re-use will mean users have to re-implement "unique_thread_id" and some really difficult-to-fix bugs for people who do not think about it. OTOH, I see some value in that std::thread::id are the same as window's thread ids when you're debugging and post-mortem debugging.
Since issue #783 is marked as ready, does it mean it is closed and the proposed text has been added to the standard? I was hoping re-use would be disallowed :/
No, it means it will be voted on at the June meeting. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi, ----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, May 28, 2008 12:47 PM Subject: Re: [boost] [thread] Are thread ids unique during an applicationslife time?
Johan Torp <johan.torp@gmail.com> writes:
Peter Dimov-5 wrote:
IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states:
"An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution."
http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#783
I also expect re-use will mean users have to re-implement "unique_thread_id" and some really difficult-to-fix bugs for people who do not think about it. OTOH, I see some value in that std::thread::id are the same as window's thread ids when you're debugging and post-mortem debugging.
Since issue #783 is marked as ready, does it mean it is closed and the proposed text has been added to the standard? I was hoping re-use would be disallowed :/
No, it means it will be voted on at the June meeting.
If the thread::id can not be reused an exception should be thown when no more ids are available. The current proposal states that a thread::id of a terminated thread that can no longer be joined is reusable, i.e. immediatlly and even if there are other ids never used available I'm working on a Locally Unique Identifier library (that work for intergral types) having the following feautures: A released id can be either: a - never reused, or b - recoverable A recoverable id can be reused A - even if there are other ids which have never been used B - only if there are no more ids which have never been used The recoverable id could be reused 1 - Immediatlly, or 2- only - after a frozen period - if there is not an older free id (fifo), i.e. first recovered first reusable The current Boost.Thread thread::id proposal corresponds to the policy b+A+1, but the thread::id is not an intergral type, so I'm not sure the above can be applied to the thread::id type. The question is which are the policies having a sens for a thread::id without implying a given representation for the thread::id type and allowing an efficient implementation? If there are several possibilities, the next questions is, should this choice be provided to the user through a given inteface? globally? per thread? or, should this choice be let to the library implementors? Any thoughts? Best regards Vicente
On May 28, 2008, at 6:42 AM, Johan Torp wrote:
I also expect re-use will mean users have to re-implement "unique_thread_id" and some really difficult-to-fix bugs for people who do not think about it. OTOH, I see some value in that std::thread::id are the same as window's thread ids when you're debugging and post-mortem debugging.
std::thread::id has one bit of functionality that may reduce the need for "unique_thread_id": It has a notion of an id that is guaranteed to be "not any thread". For example: std::thread::id id1; std::thread::id id2 = std::this_thread::get_id(); assert(id1 != id2); The assert is guaranteed to pass. So when you know that a thread is terminating, or is otherwise no longer valid, one can reset thread id's to not-a-thread: id2 = std::thread::id(); I've used this (for example) in implementing recursive mutexes: class recursive_mutex { unsigned state_; std::thread::id id_; ... public: recursive_mutex() : id_() ... // id_ guaranteed not to compare equal to any call to get_id() ... void unlock() { ... if (decrease_lock_count() == 0) id_ = std::thread::id(); // id_ guaranteed not to compare equal to any call to get_id() ... } ... }; -Howard
Howard Hinnant:
I've used this (for example) in implementing recursive mutexes:
class recursive_mutex { unsigned state_; std::thread::id id_;
As already pointed out in the thread http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.htm... linked from #783, this requires thread::id atomicity, which is not guaranteed. I'm not sure whether instant reuse can also break this particular example, but it definitely breaks other uses of thread::id.
On May 28, 2008, at 3:02 PM, Peter Dimov wrote:
Howard Hinnant:
I've used this (for example) in implementing recursive mutexes:
class recursive_mutex { unsigned state_; std::thread::id id_;
As already pointed out in the thread
http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.htm...
linked from #783, this requires thread::id atomicity, which is not guaranteed. I'm not sure whether instant reuse can also break this particular example, but it definitely breaks other uses of thread::id.
I probably made a mistake in posting code snippets instead of a complete recursive_mutex. In the example I programmed, which was actually a recurisve_timed_mutex instead of a recursive_mutex, there were member mutex and condition_variables. The mutex was locked while manipulating the internal state_ and id_, providing the required atomicity, and preventing "instant reuse". Since "not a thread" values do not exist (as far as I know) in pthreads and Windows, I was trying to make the point that many people probably haven't considered the use of such values in multithreading programming in dealing with the id-reuse-problem. I believe this tool will solve some, but not all, problems which "unique_id" addresses, and with far less expense. -Howard
participants (5)
-
Anthony Williams -
Howard Hinnant -
Johan Torp -
Peter Dimov -
vicente.botet