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