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

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

-Howard