Subject: Re: [boost] [threadpool] new version v12
From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-11-03 08:24:02
> 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