3595857849
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_().
boost.fiber
boost.fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperativly. The API contains classes and functions to manage and synchronize fibers similiar to boost.thread.
A fiber is able to store the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (threads are preemptively scheduled) - the running fiber decides explicitly when its yields to allow another fiber to run (context switching).
A context switch between threads costs usally thousends of CPU cycles on x86 compared to a fiber switch with less than 100 cycles. A fiber can only run on a single thread at any point in time.
Building: Detailed instructions can be found at https://svn.boost.org/trac/boost/wiki/TryModBoost.