Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Nat Goodspeed (nat_at_[hidden])
Date: 2015-09-06 16:19:09

On Sun, Sep 6, 2015 at 8:11 AM, Thomas Heller <thom.heller_at_[hidden]> wrote:

> 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/examples/migration.cpp#L16

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.