Path: utzoo!utgpu!news-server.csri.toronto.edu!hub.toronto.edu!thomson Newsgroups: comp.unix.internals From: thomson@hub.toronto.edu (Brian Thomson) Subject: Re: Nice Message-ID: <1991Jan31.203333.25021@jarvis.csri.toronto.edu> Organization: University of Toronto References: <1991Jan22.184055.3641@demott.com> <2004@necisa.ho.necisa.oz.au> <1991Jan31.180957.9167@turnkey.tcc.com> Date: 1 Feb 91 01:33:33 GMT Lines: 43 In article richard@locus.com (Richard M. Mathews) writes: >jackv@turnkey.tcc.com (Jack F. Vogel) writes: >>boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >>>richard@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@hub.toronto.edu