On Sun, Sep 6, 2015 at 8:11 AM, Thomas Heller
On 09/06/2015 06:12 AM, Oliver Kowalke wrote:
I don't know why you ignore the problem of TLS and compiler optimization in the context of work-stealing - this is an issue.
The Fiber library, itself however should not be affected by this. That is it can safely store a reference to the currently running fiber or thread manager in a TLS variable. The trick is, of course to update the variable on each context switch.
... it is still not in the scope of Boost.Fiber to make that decision, it should be possible to migrate fibers to other threads.
Let me put a stake in the ground: I assert that the present design of the Fiber library permits cross-thread fiber migration. The primary reason for the documented prohibition is the TLS optimization/bug under discussion. If that can be robustly overcome, the Fiber library can claim support for fiber migration. Consider this program: https://github.com/nat-goodspeed/boost-fiber/blob/shared_ready_queue/example... The library design permits a custom sched_algorithm::pick_next() implementation to return a fiber_context* from any thread. The shared_ready_queue scheduler illustrates this point. For simplicity, it is not a "work-stealing" scheduler, but rather a "work-sharing" scheduler. Obviously more sophisticated logic could be built around that notion. However -- at least with Boost 1.59.0 on Ubuntu 14.04 with gcc 4.9.2 -- the cited program pretty reliably crashes with SIGSEGV. Oliver has requested help overcoming the TLS optimization/bug. It would be wonderful if one of you requesting support for fiber migration would be willing to suggest a way for a given fiber to robustly locate the fiber_manager, and so forth.