Nice

[Brian Thomson]

In article <richard.665353961 at fafnir.la.locus.com> richard at locus.com (Richard M. Mathews) writes:
>jackv at turnkey.tcc.com (Jack F. Vogel) writes:
>>boyd at necisa.ho.necisa.oz.au (Boyd Roberts) writes:
>>>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).
>> 
>>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
>
>Thanks for the defense, Jack.  To be explicit, look for the call to
>aston() in wakeup() in a VAX kernel.  This will cause a trap to occur
>before ANY user mode instructions are executed; that is what I meant by
>"immediately".  Before that trap returns to user mode, it will notice
>runrun is set and reschedule.  In other systems (such as a few different
>80*86 kernels I've seen) both traps and interrupts check runrun before
>returning to user mode and can switch context immediately.
>

It is also checked in a few pdp11 kernels I've seen ...
UNIX (tm) has traditionally been a single processor operating system
of the "monolithic monitor" type.  That is to say, once a process begins
running in the kernel it is guaranteed that no process switch will occur
until it voluntarily relinquishes the processor by calling "swtch()",
or exits the kernel by returning to user mode.  So, all process switches,
including those caused by interrupts, are deferred until one of those
things happens.  Part of this involves checking the reschedule flag when
returning to user mode from a trap or interrupt.  The only new wrinkle
in the VAX was that the hardware would do this check for you.

This being the case, I would have to agree with Mr. Roberts that
Mr. Mathews' definition of "forced immediately" is somewhat unconventional ...
but to disagree with his assertion that the switch is delayed until the
*next* {trap, syscall, etc.}.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson at hub.toronto.edu