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

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-09 02:19:03

2015-09-09 0:19 GMT+02:00 Giovanni Piero Deretta <gpderetta_at_[hidden]>:

>
> > the scheduler maintains several queues (waiting ,ready ,...) containing
> > fiber context's
> > depending on their state (waiting, ready ,...).
>
> why are the wait queues part of the scheduler itself? Shouldn't they
> be a property of the waitable primitive?
>

the scheduler has a wait queue as well as each waitable primitve has a wait
queue.
the wait queue inside the scheduler is especially required for detached
fibers
at termination (~scheduler())

> > if a scheduler would be schedulable, it would have been a context - a
> > scheduler would then schedule itself.
> > I'm uncertain how your schedulable schedulers would fit in this pattern
> > (probably not very well).
> >
>
> One option is scheduling schedulable entities. Something like
>
> schedulable {
>  schedulable * next, * previous;
>  void (*run)(schedulable*self); // or use a virtual
> };
>
> but there are of course advantages in knowing that each schedulable is
> a contex as you can swapcontext to it.
>

the scheduler simply know which fiber can be resuemd next.
if fiber f1 has to suspend (maybe joins another fiber) it calls the
scheduler
to select the next fiber f2 and transfer execution control to fiber f2
(context switch).
the process of selecting the next fiber and calling the context switch are
running
inside fiber f1. that means that we have a call chain between fibers.

I'm uncertain what schedulable::run() should execute if the schedulable is
a scheduler
and a context switch is called (what doesn't make sense to me).

> Ok, I went and looked at the code. I see that on wakeup, the context
> is simply marked as ready. The main scheduler loop, after each
> scheduling event goes through the wait list and moves ready contextes
> to the main thread.

not main thread - it moves fibers, that have been signaled as ready, from
the waiting queue
to the ready queue (that is sched_algorithm::awakened() is used for).
sched_algorithm::pick_next() selects a fiber from its internal ready-queue.

> This is how I would expect a scheduling algorithm to work:
>

<snip>

I've to think about your suggestion how it could applied to the current code