Re: [boost] Boost.Threads, N2178, N2184, et al

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-21 18:56:35

On Mar 21, 2007, at 6:01 PM, Emil Dotchevski wrote:

>
>> *  The N2184::thread is non-copyable like boost::thread, but movable
>> (taking advantage of new C++ language and std::lib features).   
>> Movable
>> N2184::thread maintains the one-to-one mapping between the  
>> std::thread
>> and the OS thread which boost has (sole ownership semantics).  It  
>> just
>> adds the ability to move the thread between scopes (such as return
>> from factory functions).  I recently drew the analogy this way:
>>
>> boost::thread is like a scoped_ptr to the OS thread.
>> N2184::thread is like an auto_ptr to the OS thread (the proposed
>> unique_ptr would be a more accurate analogy).
>
> This assumes that it is not desirable for the same N2184::thread  
> object to
> be shared between multiple owners. The rationale given for the non- 
> copyable
> semantics of boost::thread states that the only time you need copyable
> handle is in what they call "Use case 6: Creation of a thread whose
> ownership is shared between multiple objects", which is like saying  
> that you
> only need shared handles when you need shared handles
> (http://www.boost.org/doc/html/threads/rationale.html#threads.rationale.non-copyable.shared.www.boost.org/ 
> doc/html/threads/rationale.html#threads.rationale.non- 
> copyable.shared.)
>
> I suppose similar argument can be made for movable semantics for
> N2184::thread, but again, what about this use case? Does N2184 argue  
> that
> this use case does not exist in practice?

For this use case, N2184 argues that the use case should be supported  
with a higher-level library which sits non-intrusively on top of  
std::thread.  My preferred name for this is std::shared_future (though  
std::tr2::shared_future is a more likely name).  shared_future would  
be copyable, multi-joinable, and would deliver both normal and  
exceptional results from an asynchronous job when the shared_future is  
joined with.

The advantage of putting this functionality in a separate class is  
that it costs space and time.  And for clients that do not need this  
functionality it seems like a shame to force them to pay for it.  So  
the big picture is to provide a series thread management objects: from  
low level to high level, with the lowest level being relatively small,  
cheap and fast, but lacking features.  And the highest level adding  
all the niceties along with the subsequent cost.  And it is hoped and  
anticipated that the highest level objects will end up being the most  
commonly used.  std::thread is targeted at the very lowest level in  
this plan -- a solid foundation upon which much cooler stuff can be  
built: not only by std::lib vendors, but by anybody - portably.

Peter Dimov and Ion Gaztanaga have both implemented shared ownership  
thread manager objects (i.e. future) on top of boost::thread (non- 
intrusively).  I'm extremely grateful for their ground breaking proof  
of concept work showing that we don't need a copyable low level to  
support a copyable higher level.  And this statement is not meant to  
imply that either Peter or Ion support or approve of the non-copyable  
(but move-only) lower level, so I feel a little guilty about stating  
it.  But nevertheless I am grateful.

And fwiw, N2184::thread delivers a std::thread which I believe has the  
more common motivations for a copyable std::thread:  You can return it  
from factory functions and you can put into std::containers.  These  
actions will only require movability, not copyability, in C++0X.

-Howard