From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-28 18:23:47
Hi,
----- Original Message -----
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 28, 2008 12:47 PM
Subject: Re: [boost] [thread] Are thread ids unique during an
applicationslife time?
> Johan Torp <johan.torp_at_[hidden]> 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