Nice

Jack F. Vogel jackv at turnkey.tcc.com
Fri Feb 1 05:09:57 AEST 1991


In article <2004 at necisa.ho.necisa.oz.au> boyd at necisa.ho.necisa.oz.au (Boyd Roberts) writes:
>In article <richard.665126102 at fafnir.la.locus.com> richard at locus.com (Richard M. Mathews) writes:
>>...  In many (most?) versions of Unix if an interrupt
>>makes a process runnable at a higher priority than the running process,
>>a context switch will be forced immediately.
 
>No, UNIX does not have pre-emptive scheduling.  When the above event occurs
>the kernel context switches at the next user-mode trap, system call, sleep()
>or the once-a-second context switch (time quantum expiry).
 
I think you are nit-picking at Richard's choice of words here. When he said
"immediately" it was in a loose sort of sense, not suggesting some sort of
preemption at that instruction. But it is also not correct that a context
switch will take as long as you suggest. What will happen is that the
interrupt will cause the kernel to run in trap(), there it will do whatever
serving needs to be done, lets say an event occured that another process was
sleeping on, this will cause that process to be put back in the run queues,
and runrun will be set true, then at the exit of trap there is a test of
runrun and as it will be true a context switch will take place right then.
No need for another system call, sleep(), or whatever.

>....  A higher priority process being made runnable doesn't
>_force_ the current process to give up the CPU, it gives it up when it
>notices that it has to.
 
Now you talk as though there is no such thing as "preemption" at all, the
running process is "forced" to give up the CPU whenever an involuntary
context switch takes place. Perhaps its just a semantic preference to say
"it notices that it has to" :-}.

Disclaimer: I don't speak for LCC.

-- 
Jack F. Vogel			jackv at locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv at turnkey.TCC.COM



More information about the Comp.unix.internals mailing list