Re: [boost] [fiber] on schedulers and wakeups

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-09-09 07:38:04

> Oliver Kowalke <oliver.kowalke <at> gmail.com> writes:
> > 2015-09-09 0:19 GMT+02:00 Giovanni Piero Deretta <gpderetta <at>
> gmail.com>:
> > > On Tue, Sep 8, 2015 at 7:21 PM, Oliver Kowalke <oliver.kowalke <at>
> gmail.com> wrote:
> > > > 2015-09-08 13:34 GMT+02:00 Giovanni Deretta <gpderetta <at>
> gmail.com>:
> > > >> My first concern is that scheduler is a global (per thread)
> property.
> This
> > > >> makes sense, but it limits its usability in libraries, unless the
> library
> > > >> completely owns a thread.
> > > >
> > > > the scheduler is only entered if a function from boost.fiber is
> called.
> > > > code outside of fiber code is ‎unaffected
> > > > how does it limit the usability?
> > >
> > > Two different libraries can't use boost.fiber if they require a custom
> > > scheduler or they need to run their own threads. Basically the
> > > scheduler is a scarce resource and limits composability.
> >
> > OK, good point!
> > One of the design decisions for boost.fiber was that the scheduler
> itself
> > is not visible
> > (the user code does not instantiate it). the library should work similar
> to
> > std::thread
> > (os-scheduler not visible ...).
> 
> The point is that the scheduler is not completely invisible as it can be
> replaced. As the default scheduler is very basic, replacing it becomes
> pretty much a requirement.
> 
> >
> > of course if this decision is given up, the user creates (on stack or
> heap)
> > a scheduler
> > and if a new fiber is created the code must specify to which scheduler
> the
> > fiber belongs to.
> >
> > my_scheduler ms;
> >
> > fiber f( ms, fn, arg1, arg2),
> 
> Specifying an explicit scheduler would be a nice addition, but if not
> specified, it should default to the current scheduler for the thread.

Hmmm, I would prefer if the scheduler and fiber interfaces were left orthogonal. A fiber is just a callable, its API shouldn't have a notion of where it is run. I'd like to see something like this instead:

// asynchronous execution
T fn(Arg...) {...}

fiber_executor exec;
future<T> f = executor_traits<fiber_executor>::async_execute(bind(fn, arg...));

or 

// synchronous execution
executor_traits<fiber_executor>::execute(bind(fn, arg...));

(see N4406, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf)

That would also provide an uniform interface for other means of work-scheduling. Also users can easily implement their own executor.

FWIW, we have implemented something similar in HPX and it works very well (see for instance http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel/executors.html).

> > in the context of migrating fibers between threads:
> >
> > - in the current design only single fibers are moved between schedulers
> > running in different threads
> > - you suggest that the scheduler itself is moved between threads?!
> >
> 
> As I suggested elsethread, a child scheduler would appear to the parent
> scheduler as another fiber, so if that fiber is migrated, the whole
> scheduler is.
> 
> > > > It would be nice if schedulers where schedulable
> > > >> entities themselves, so that they could be nested (more at the
> end).
> > > >
> > > > in the current design each thread has one scheduler (the scheduler
> is
> > > > hidden).
> > > > a scheduleable entity is a fiber context (fiber's stack), that means
> that
> > > > each boost::fibers::fiber is attached to one fiber context
> (detaching
> a fiber means decoupleing from
> > > > the context).
> > >
> > > how do you detach a fiber by a context? What does it mean? Did you
> > > mean detach a fiber+context from a scheduler?
> > >
> >
> > boost::fibers::fiber has a member pointer to boost::fibers::context
> > boost::fibers::scheduler manages boost::fibers::context *
> > detaching means boost::fibers:.fiber relases its pointer to
> > boost::fibers::context.
> >
> > the scheduler still manages (scheduling/lifetime) the detached context
> > (boost::fibers::context is a control structure
> > residing on the top of the fiber-stack)
> >
> 
> Ok, I think I understand; I was thinking about fiber the abstract concept,
> while you of course meant the boost::fiber::fiber class, which can be
> detached like an std::thread.
> 
> Although now I can't see how detaching is relevant to the nested scheduler
> discussion...

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu