[squeak-dev] Re: Suspending process fix

Michael van der Gulik mikevdg at gmail.com
Wed Apr 29 04:04:54 UTC 2009


On 4/29/09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Andreas,
>
> On Tue, Apr 28, 2009 at 8:33 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

>> This is actually along similar lines of thought that I had when I was
>> thinking of how to get rid of the builtin VM scheduling behavior. The main
>> thought that I had was that the VM may have a "special" process - the
>> scheduler process (duh!) which it runs when it doesn't know what else to
>> do.
>> The VM would then not directly schedule processes after semaphore signals
>> but rather put them onto a "ready" queue that can be read by the scheduler
>> process and switch to the scheduler process. The scheduler process decides
>> what to run next and resumes the process via a primitive. Whenever an
>> external signal comes in, the VM automatically activates the scheduler
>> process and the scheduler process then decides whether to resume the
>> previously running process or to switch to a different process.
>>
>> In a way this folds the timer process into the scheduler (which makes good
>> sense from my perspective because much of the work in the timer is stuff
>> that could be more effectively take place in the scheduler). The
>> implementation should be relatively straightforward - just add a scheduler
>> process and a ready list to the special objects, and wherever the VM would
>> normally process switch you just switch to the scheduler. Voila, there is
>> your user-manipulable scheduler ;-) And obviously, anything that is run
>> out
>> of the scheduler process is by definition non-interruptable because there
>> is
>> simply nothing to switch to!
>
>
> How would you generalise this to a natively multi-threaded VM?  Obviously
> one simple way is to stop the other processors at a suspension point before
> letting the scheduler process proceed, but is there anything cleverer that
> doesn't halt all processors until the singleton scheduler has made its mind
> up?

Every OS thread would have it's own scheduler process. Each scheduler
process has it's own data structure (collection of process lists in
runlevels / balancing tree / whatever) which it has complete ownership
over meaning that it doesn't need to synchonise access to it. Each
process has affinity with a particular scheduler so that the
interrupt-like mechanism Igor mentioned would hold only for that
particular scheduler instance and it's associated list/tree/whatever
of processes.

Each scheduler process would then communicate with other scheduler
processes using something like... umm... a shared queue of messages
that it would poll on... or something. I haven't thought out all the
details here yet. The communication would be necessary for (at least:)

* moving processes between schedulers. This would happen when a
scheduler goes idle so that load balancing happens.

* signalling semaphores where the waiting process belongs to another scheduler.

* and other stuff I haven't thought of yet.

Gulik.

-- 
http://gulik.pbwiki.com/



More information about the Squeak-dev mailing list