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
|