Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-25 14:49:07

On Mar 25, 2007, at 12:03 AM, Emil Dotchevski wrote:

> If I have shared thread handles, I can associate arbitrary data with
> a thread by a map<handle,data>. Independently, somebody else may
> have their own map<handle,data>. If I use thread::id in a similar
> way, how do I know when to dispose of the associated data? (if I
> remember correctly, if I have a thread::id, I can't check whether
> the corresponding thread has ended.)

<nod> You are correct. With a non-copyable std::thread one would need
to create a signaling mechanism (i.e. cv/mutex) to look up the
thread::id in the map and invalidate it (by setting it to "not any
thread", or just erasing it). Or alternatively you could reference
count the data and associate a more permanent id with it. Indeed this
is exactly what a copyable std::thread would need to do. The big
question is: do you want to pay for this functionality all of the
time? Or only when you need it?

N2184 takes the minimalist approach. It is easier to add
functionality (and the associated expense) than to subtract it. There
are many things the N2184::thread does not directly support. I
believe this is a feature, not a bug.

Drawing the line between what functionality can be had for free, and
what functionality should be relegated to higher level types built
upon thread has been a challenging exercise (although boost::thread
was an excellent starting point). It is very easy (and very tempting)
to keep adding features to a type (e.g. and with just one more level
of indirection look at this new cool thing it will do!). The
philosophy behind N2184 is to only add functionality which is either
free, or can not be added on by a higher layer. Unfortunately
cancellation was not free to add. But I could not figure out a
practical way to layer it on, and the LWG assured me that this one
feature was worth extra cost even at the very lowest most primitive
layer (and that has been my sense from the boost community as well: "I
want boost + cancellation").

For those that want "boost + cancellation + X" where "X" might be
"multi-join" or "copyability", exception propagation or whatever,
N2184 does not refuse or ignore the request. N2184 delegates that
functionality to some other class that can be non-intrusively layered
on top of N2184::thread without suffering any significant performance
hits (i.e. there should be no motivation for this client to bypass
N2184::thread and code at the OS level).


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