"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).
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.
That depends on the thread-local variable. errno is used everywhere, so it is not safe to assume it is unchanged. You might expect a library specific thread-local to persist across a future wait: the futures library knows nothing of your code, so has no reason to write to your thread locals. Unless of course it runs another task on your thread.... Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK