Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-11-03 08:24:02

Anthony Williams:
> Fibers are still tied to a particular thread, so thread-local
> variables and boost::this_thread::get_id() still return the same value
> for a nested task. This means that a task that calls future::get()
> might find that its thread-local variables have been overwritten by a
> nested task when it resumes. It also means that any data structures
> keyed by the thread::id may have been altered. Finally, the nested
> task inherits all the locks of the parent, so it may deadlock if it
> tries to lock the same mutexes (rather than just block if it is
> running on a separate thread).

No. If task A holds a mutex M and waits for task B, and task B tries to lock 
M, you have deadlock no matter which thread executes B.

For the thread locals, they usually are altered in the manner they should've 
been altered, unless a task uses thread locals instead of ordinary locals 
and calls itself. Expecting errno to persist across a future wait (or across 
an arbitrary function call) is not a reasonable assumption.

--
Peter Dimov
http://www.pdplayer.com