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

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 
of N2185.

Here's a link that discusses the problem with fixed thread pools:

http://www.bluebytesoftware.com/blog/PermaLink,guid,ca22a5a8-a3c9-4ee8-9b41-667dbd7d2108.aspx