Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-10 05:19:25

2014/1/10 Antony Polukhin <antoshkka_at_[hidden]>

> Do not remove schedulers. Just remove "algorithm" from docs and hide it in
> namespace detail.
>

OK

> My concern is that fiber migration between threads is a rare case.
>

yes/maybe - I've introduced this in order to support work-stealing in
thread-pools

> So first of all fibers must be optimized for a single threaded usage. This
> means
> that all the thread migration mechanics must be put in scheduler, leaving
> fiber light and thread unsafe.
>

that's already reality.
suppose you want to migrate a fiber from thread A to thread B using
round_robin_ws as
the fiber-scheduler (each thread has running an instance of this class).
Thread B accesses the fiber-scheduler of thread A by calling
round_robin_ws::migrate_from().
this function selects a fiber (ready to run) from the ready-queue and adds
this fiber
to its own internal read-queue.
the access to the ready-queue must be thread-safe in round_robin_ws.

In contrast to this class round_robin does not support fiber-stealing and
thus does not
protect its internal ready-queue for concurrent access from different
threads.

> What if round_robin scheduler be a thread local variable (just like now,
> but without any thread sync), but for cases when fiber migration is
> required a global round_robin_ws scheduler is created for all the threads?
> In that way we'll get high performance in single threaded applications and
> hide all the thread migrations and sync inside the thread safe
> round_robin_ws scheduler.
>

see above - the current implementation already separates a 'thread-safe'
scheduler from an un-safe

mutex and condition_variable must be thread-safe because it could be
executed concurrently in different threads.

the only class which could be optimized would be fiber_base itself, e.g.
the accesss to the internal state must be threadsafe
(currently done via an atomic). of course this atmoic is not required if
the fiber runs in a fiber-scheduler which
does not support fiber-migration. threfore, as you already mentioned, it
would be an optimzation to move the management of
fibers internal state into the scheduler itslef (for instance internal
class schedulable). The scheduler determines if accessing
the internal state is thread-safe or not.

>  Is that easy to implement?

at the first look, yes

> Does it scale well with proposal of thread
> unsafe round_robin and thread safe round_robin_ws?
>

it doesn't matter if you update the state in the fiber_base or in the
scheduler - you have the same amount of function calls.
the benefit is that you don't update atomics in the thread unsafe
round_robin class.