[squeak-dev] Re: Suspending process fix

Denis Kudriashov dionisiydk at gmail.com
Wed May 6 19:42:49 UTC 2009


2009/4/29 Michael van der Gulik <mikevdg at gmail.com>

> 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/
>
>
Communication between local schedulers could be controlled by special global
scheduler on the language side too (load balancing...).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090506/7d7c4221/attachment.htm


More information about the Squeak-dev mailing list