While it's true that not every READY fiber is always in the scheduler's ready
queue -- there's a time window in which a READY fiber can be on the
fiber_manager's wait queue -- only READY fibers will ever be on the
scheduler's ready queue. So if (! fiber.is_ready()), there's no point in
bothering the sched_algorithm implementation with a change to its properties.
sched_algorithm knows nothing about properties, so that class isn't really the
best place for the property_change() virtual method. Introduce intermediate
sched_algorithm_with_properties_base class, which introduces property_change_()
virtual method accepting fiber_properties*. Then the properties-specific
sched_algorithm_with_properties<PROPS> implementation calls property_change()
(no trailing underscore) with fiber_properties* cast to PROPS&. Thus the user-
coded sched_algorithm implementation can override property_change() and accept
PROPS& rather than the generic fiber_properties* pointer. But
fiber_properties::notify() -- which doesn't know its own PROPS subclass -- can
nonetheless call sched_algorithm_with_properties_base::property_change_().
Priority is another property that's only relevant for future sched_algorithm
implementations. We don't even have an example yet. It's a good candidate for
moving to a specific fiber_properties subclass for that specific
sched_algorithm implementation.
Specificaly, remove access methods in worker_fiber, fiber and this_fiber.
thread_affinity is not used by any present library code. It was intended for
use by workstealing user sched_algorithm implementations. The properties
mechanism is a better way to address scheduler-specific properties.
Some reviewers disliked that to build a custom sched_algorithm subclass, you
must necessarily manipulate pointers to classes in the boost::fibers::detail
namespace. Redefine all such methods to use fiber_base* rather than
detail::worker_fiber*.
Hoist fiber_base* into boost::fibers namespace. We considered an opaque
typedef rather than fiber_base*, but in fact a sched_algorithm subclass may
need is_ready().
Moreover, a sched_algorithm subclass may well want to use an intrusive linked
list to queue fibers. Hoist worker_fiber::nxt_ pointer into fiber_base, and
remove worker_fiber::next() and next_reset() methods. This allows recasting
detail::fifo in terms of fiber_base*, therefore round_robin can be stated
almost entirely in terms of fiber_base* rather than worker_fiber*.
Recast fiber constructor taking worker_fiber* to take fiber_base* instead.
This constructor is used solely for fiber migration; with relevant functions
now returning fiber_base*, we think we no longer need fiber(worker_fiber*).
Instead of setting a fiber_properties subclass's sched_algo_ back pointer once
at construction time, unconditionally set it every time that fiber becomes
READY (and is therefore passed to sched_algorithm::awakened()). This handles
the case in which that fiber migrates to a different thread with a different
sched_algorithm subclass instance.
Break out fiber_properties::notify() implementation to a separate .cpp
implementation file so it can bring in algorithm.hpp. We don't want
properties.hpp to depend on algorithm.hpp.
Introduce fiber_properties class from which to derive a specific properties
class for a particular user-coded sched_algorithm subclass.
Add sched_algorithm::property_change(worker_fiber*, fiber_properties*) method
to allow a fiber_properties subclass method to notify the sched_algorithm
subclass of a change in a relevant property. This generalizes the present
priority() method.
Introduce sched_algorithm_with_properties<PROPS> template class from which to
derive a user-coded scheduler that uses fiber_properties subclass PROPS. Give
it ref-returning properties(fiber::id) and properties(worker_fiber*) methods.
Introduce fiber_properties* field in worker_fiber, and initialize it to 0.
Delete it when the worker_fiber is destroyed. Give it pointer-flavored access
methods. Normally this field will remain 0; but the first time the
worker_fiber is passed to a sched_algorithm_with_properties<PROPS> subclass,
its awakened() method will instantiate the relevant PROPS subclass.
Add ref-returning fiber::properties<PROPS>() method. Calling this method
presumes that the current thread's sched_algorithm is derived from
sched_algorithm_with_properties<PROPS>.
Also add this_fiber::properties<PROPS>() with the same restriction.
Add ref-returning fm_properties<PROPS>() functions to implement
fiber::properties<PROPS>() and this_fiber::properties<PROPS>().
Allow sched_algorithm_with_properties to extract the worker_fiber* from a
fiber::id (aka worker_fiber::id) so it can present public-facing
properties(id) method as well as properties(worker_fiber*) method.
(cherry picked from commit 18c7f2c13b9642826b42aa3f6fa0a6642fce9cbc)
Conflicts:
include/boost/fiber/detail/worker_fiber.hpp
include/boost/fiber/fiber_manager.hpp
- in previous version active-fiber is stored in ready-queue
even if active-fiber is in state RUNNING
-> triggers segmentation faults if fiber gets migrated
