[Boost-users] Re: thread::thread() in Windows

From: Martin Pasdzierny (martin_at_[hidden])
Date: 2004-12-10 14:46:10

Hello boost::thread experts,

does the 'thread_ref-design' as discussed previously enable the following scenario ?

<code start>

struct thread_class_1 {
        thread_ref tr;
        void operator()() {
                tr = get_current_thread_ref(); // view from *inside* a thread
                ...
        }
} ;
...
thread_class_1 thread_functor_1;
boost::thread thread_1(thread_functor_1) ;
...
// assume the thread really started in the meantime ...
thread_ref tr_1 = thread_functor_1.tr; // view from *outside* a thread
// assume  the thread is still working ...
thread_ref tr_2 = thread_1.get_thread_ref(); // view from *outside* a thread
...
<code end>

Now tr_1 == tr_2 evaluates to true.

To my understanding the current implementation of boost::thread does not allow easy comparison of threads
from *inside* and *outside*.

Grouping the boost::thread members m_thread,m_id,.. into a comparable type (e.g. named thead_id)
and exposing this id at least 'protected' would make user extensions more flexible.

Thanks for any reply, Martin.

Peter Dimov wrote:
> Yuval Ronen wrote:
> 
>> I believe that we are going a bit off the topic here, but I'll go
>> there with you.
>>
>> What you are suggesting, is that what we now know as 'thread' will be
>> transformed into 'thread_impl' and will be hidden from the user,
>> which will only know about thread_ref (actually a
>> shared_ptr<thread_impl>). First of all, in no way do I dismiss this
>> proposal. But what is the difference between this and the current
>> design?
> 
> 
> The difference is:
> 
> Current design:
> 
> (thread data, including function object)
> (thread class, noncopyable)
> 
> thread_ref design:
> 
> (thread data)
> 
> The current design has two logical object per thread, one that remains 
> alive until the thread finishes execution, another that is created by 
> the user and can be destroyed at any time.
> 
>> Another thing: if we want a
>>     thread_ref current_thread();
>> function, how will it be implmented?
> 
> 
> A thread_ref is held in thread-specific storage (keeping the thread 
> object alive for the lifetime of the thread as a side effect) and is 
> returned by current_thread().