Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-11-03 10:34:30

Anthony Williams:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> 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.
>
> That's true if the thread runs task B whilst it is waiting. If it runs
> task C which is completely unrelated and task C tries to acquire the
> lock then it will deadlock even if task B then completes, which would
> allow task A to resume and release the lock (since task A is suspended
> whilst its thread runs task C).

Yes, of course. If A waits for B, the pool should try to execute B in A's 
thread, not C.

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