Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!spool.mu.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!fafnir.la.locus.com!richard From: richard@locus.com (Richard M. Mathews) Newsgroups: comp.unix.internals Subject: Re: Nice Message-ID: Date: 31 Jan 91 20:32:41 GMT References: <1991Jan22.184055.3641@demott.com> <2004@necisa.ho.necisa.oz.au> <1991Jan31.180957.9167@turnkey.tcc.com> Organization: Locus Computing Corporation, Los Angeles, California Lines: 27 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. Richard M. Mathews Freedom for Lithuania richard@locus.com Laisve! lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard