[Stackless] Preliminary pre-emptive scheduling is there

Christian Tismer tismer at tismer.com
Mon Sep 8 13:13:59 CEST 2003


Hi friends,

thanks to Richard Emslie, there is some preliminary
pre-emptive scheduler available in Stackless 3.0.

This is not final, the interface might get improved
a little bit, but *it works*.

For sample code, please see the folder stackless/emslie.

Note the new CVS repository:

CVSROOT=:pserver:anonymous at centera.de:/home/cvs
export CVSROOT
cvs login
cvs co stackless

I'd like to have your input how things should actually
be laid out.
Currently, the stackless.run function has a parameter
that tells after how many cycles without task switching
a tasklet should be called "doomed" and be interrupted.
This is kind of a watchdog timer.

Now, there is a global flag enable_autoscheduling, which
controls wether the run function acts as a watchdog
timer or as a pre-emptive scheduler. The parameter
then turns into the number of ticks per time slice.

I need your input how to handle this better, in a simple
and quick solution. The long-term goal is to have
an extra scheduler object, which is responsible to
all kind of stuff concerning task switching, which can
be overwritten in Python. The current run function
will then become a method of the scheduler object.
But this is just music from the future.

Right now, I need a concept that allows to have pre-emption
together with watchdog behavior.
Here the problem:

Until now, all tasklets are switched explicitly, and
in most cases, this is what people want. The purpose
of the run() function is just to have a bunch of
tasklets run until they are all gone, and to keep
an eye on too long running tasklets.

Now, in provision for pre-emption, there has been
a so-called atomic flag for quite some time, but
it wasn't used, yet. The purpose of that flag is
to inhibit auto-scheduling in critical sections.
Every tasklet has such a flag.
This flag is partially auto-maintained and acts
as a safety belt for the system. Whenever a tasklet
enters a recursive C interpreter level, the atomic
flag is set. Reason: In such a context, I cannot
know whether an extension module has been involved,
and I don't know whether this module can stand
switching the C stack. Therefore, the atomic flag
conservatively inhibits auto-scheduling of such
tasklets, in order to avoid system crashes.
Of course, this flag can be reset by hand, if
you know your context better and there is no danger.

Back to the problem:
run() uses a callback function which is called every
n Python opcodes, to see if the timeout of the
current tasklet has been reached and if an action
has to be taken.
The problem is now, that the actions to be taken
are no longer unique. If auto-scheduling is used,
the atomic flag comes into play.
If the tasklet is not atomic, it can be auto-scheduled,
and the callback should use the time slice information
to decide whether to switch.
But the atomic flag may be set at any time, and then
the callback should behave like the watchdog timer
and just look if a tasklet is blocking the switching
for very long time.

May idea was to provide a secnd parameter to run(),
the first is the timeout (default 0), the second is
the time slice (default 0), and the features are
only activated if the according parameter is not 0.

Does that make sense? Is that enough?
Do we eventually have another tasklet flag, which
tells whether this tasklet *wants* to be auto-scheduled?
The latter would decouple things, since the information
"I'm in a critical section" is not necessarily the
inverse of "I want to be auto-scheduled".

Please let me know your opinions.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless




More information about the Stackless mailing list