Preemptive scheduling

tim Rowledge tim at rowledge.org
Tue May 1 23:15:07 UTC 2007


On 1-May-07, at 1:51 PM, J J wrote:

>
>> You can easily do this in Smalltalk in a portable way; just a  
>> high  priority process that cycles on a time interrupt to shuffle  
>> the  process scheduler. You can manually shuffle the processes at  
>> the  various priorities if you want to.
>
> I'm good with a time interrupt, but how is that done in a remotely  
> portable/safe way?  I'm not asking about process shuffling, I'm  
> asking how a process that consists of:
>
> [ [ true ] whileTrue: [ true ] ] fork
>
> can ever be taken off the processor.  Unless you do either (a)  
> instruction count based preemption or (b) time based (i.e. what  
> CPU's use), it can't be done afaik.

The VM theoretically does a process switch check in between each  
bytecode and so if there were a higher priority process ready to run  
then it would get to take over the cpu at such a time.  If there is  
no such process then of course the loop gets to keep running.
In practise, a long time ago we moved away from that super- 
finegrained approach because it was very expensive for typical cpus;  
for WCS/microcodable machines it was generally perfectly ok. It is  
still possible to implement the check for every bytecode with  
reasonable efficiency if you're clever.
In general these days the VM (logically) does a process switch check  
anytime there is a backward branch (see , we caught the whileTrue  
loop) or a message send. This is less frequent than every bytecode  
but only by about an order of magnitude or so. When you're able to  
run 400,000,000 bytecodes per second this is not likely to be a big  
worry.  (That's the performance on my $1000 low-end macbook by the way).
To further amortise the cost of the somewhat longwinded process  
switch checks whilst still attempting to keep good interactivity, we  
actually have a counter that is decremented for each sorta-check and  
we do a real check on that counter hitting 0. It's a bit more complex  
in detail but that will do for now. We had a long mail thread and a  
lot of work about three years ago on this subject. You might like to  
search og
    Re: [BUG] User interrupts no longer interrupt locked UI process
on the mailing list archives.

We *can* interrupt that whileTrue loop (I just did); I don't know who  
told you it wasn't possible but they simply said it wrong. One case  
that can appear to be intractable is a very fast recursion, where it  
is quite possible (as in I have documented cases) to use up all of  
memory so quickly that you can't hit the interrupt key(s) before  
you're dead.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Asking whether machines can think is like asking whether submarines  
can swim.





More information about the Squeak-dev mailing list