From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-25 15:07:30
Howard Hinnant wrote:
> On Mar 25, 2007, at 12:03 AM, Emil Dotchevski wrote:
>> On Windows, you can have two joins on the same thread. Copyable
>> thread handles can support this behavior directly. How does one
>> achieve the same thing with N2184::thread semantics?
> You put a N2184::thread on the heap, with a condition variable, mutex
> and reference count accompanying it. You then create a copyable
> handle to this struct which manages the lifetime with the reference
> count, and access to the thread (and other state such as whether the
> thread as ended or not).
It probably should be noted here that a Windows implementation of N2184 can
support multiple concurrent joins (and try/timed joins) directly without
much effort. Based on a cursory look it seems that Anthony's implementation
does (minus the try/timed joins, of course, but they appear trivial to add).
As a motivating example for try joins, you might consider doing a prototype
of a thread pool that dynamically varies the number of its threads.
(Spawning new threads when a task is waiting more than a set amount of time
avoids deadlocks in the general case.) One would like the 'extra' threads to
terminate after a set amount of inactivity, and one would also like to
periodically sweep the pool container to remove these terminated threads
from it. I'll probably need to produce such a thread pool based on
N2178::handle anyway to address the potential deadlock in my implementation
Here's a link that discusses the problem with fixed thread pools:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk