2014/1/10 Antony Polukhin
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.