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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-25 16:31:47

> 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?
 
Do I read you correctly that you agree that copyable thread handle semantics are useful but you are concerned about overhead?
> 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.
 
I wouldn't dare calling it a bug. I know N2184 is a series of carefully crafted design choices, much like N2178 is.
 
I understand that N2184 is meant to be a low level interface, on top of which one can build more powerful abstractions. From this perspective, N2178 is a higher level interface indeed. 
 
N2184 begins where pthread ends; N2178 needs an extended pthread interface to be able to express its higher level C++ abstraction.
 
>From a certain point of view, the question is, which one of the two abstractions -- standard pthread, or extended pthread -- is more appropriate. What makes the answer complicated is that the lowest level interface available on Windows is more like extended pthreads than standard pthreads.
 
The net effect of adopting N2178 is that a posix implementation will have to extend the pthread interface, and a Windows implementation will have to implement it. Do this, and there's no overhead in N2178.
 
The net effect of adopting N2184 is that a posix implementation becomes trivial. On Windows, there is an issue: N2184 is too low level. Doing things that the OS supports natively -- multiple joins being an example -- comes at an additional cost, because N2184 forces user code to do synchronizations that are not necessary. This results in overhead at best, the other possibility being non-portable code.
> 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).
 
I am not an expert so I may have everything all wrong, but it seems to me what you say is only true on Posix.
 
Emil Dotchevski
_________________________________________________________________
Live Search Maps – find all the local information you need, right when you need it.
http://maps.live.com/?icid=wlmtag2&FOR M=MGAC01