Boost logo

Boost :

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
> (
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at