Anthony Williams:
"Peter Dimov" <pdimov@pdimov.com> 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