Preemptive scheduling

John M McIntosh johnmci at smalltalkconsulting.com
Tue May 1 20:26:18 UTC 2007


On May 1, 2007, at 12:05 PM, J J wrote:

> Aha, Interpreter!  I was looking in process for the "swap" method. :)
>
> At the moment, I am not looking to solve a problem per se.  I was  
> just thinking that Smalltalk tries to be it's own OS, kind of.  I  
> wonder what would happen if it went a bit further.
>
> On a real OS, a processes are only allowed to run for a certain  
> amount of time before the CPU interupts them and puts the OS back  
> in control to decide what to do next.  In any kind of "green  
> threads" system this (normally) isn't doable because it is actually  
> just one running process and if a "green thread" doesn't want to  
> yield, then the threading system never gets back in control to stop  
> it.  The threading system could, of course, have the OS send it  
> some kind of signal ever so many milliseconds but how that is done  
> is very platform specific (not to mention a host of other problems  
> with it).
>
> But with an interpreter it would be possible to do the same things  
> an advanced OS does, let a process only run for a specific amount  
> of VM instructions, penilize processes that keep using their whole  
> "quantum", promote processes that don't, etc.
>
> The question is, would this have any benifit? If I ever have time,  
> maybe I will find out (unless of course Squeak already does most of  
> this). :)


Ok, well as noted in http://groups.google.com/group/strongtalk- 
general/msg/5e36e34c2f91eb23

> But, as David pointed out, some
> > subtle bugs will turn up if you do this.

Right now processing switching occurs at known times, what they are  
I'll let someone else point out.  Those "safe points" David aludes to.

However if you were to alter the VM such that say that a process  
switch could  occur between the execution of any two bytecodes, then  
well subtle bugs in how Class methods assume control is theirs for a  
certain quantum of time would be violated.

In general the Smalltalk class library isn't written with such  
interesting side effects in mind.


Now as for experimenting, you'll find that transferTo: is the only  
place in the VM where the process switch happens.
Years ago I constructed a VM where we would collect clock time ticks  
into slots in Process instances based on doing
the calculations in transferTo:   You likely could do the same here  
by counting byte codes executed in the interpreter loop, then
collecting that data into slots in Process.

Then having a high priority task wake up and look at that data you  
could I think do some experiments. Likely then you could
distribute bytecode time equally then between N processes that are  
doing [true] whileTrue: []

mmm maybe consider priority inversion well you are tinkering too?

http://en.wikipedia.org/wiki/Priority_inversion

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===





More information about the Squeak-dev mailing list