"Oliver Kowalke" <k-oli@gmx.de> writes:
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).
OK - yes.
If the fibers are not moved to other worker-threads this shouldn't be an issue - right?
No. The problem is if I am a task running on a worker thread, and I call future::get(), if another task/fiber gets scheduled on my thread then it inherits my locks, thread-local variables and thread ID. Also, I just remembered that on Windows prior to Vista, SwitchToFiber will not preserve floating-point registers and state. On Vista, you have to specify FIBER_FLAG_FLOAT_SWITCH in the CreateFiberEx call in order to enable this. I don't know how much of a problem that is in practice.
I read in some news-groups that at least on POSIX platforms the interaction between fibers and threads is not defined - maybe the post was related to the thread-specific stuff.
I don't know much about fibers on POSIX. 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