Xref: utzoo unix-pc.general:2397 comp.sys.att:5742
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!rochester!pt.cs.cmu.edu!cadre!pitt!amanue!jr
From: jr@amanue.UUCP (Jim Rosenberg)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Question about windows and processor time (3b1)
Message-ID: <450@amanue.UUCP>
Date: 4 Mar 89 23:30:31 GMT
References: <356@flatline.UUCP>
Reply-To: jr@amanue.UUCP (Jim Rosenberg)
Organization: Amanuensis Inc., Grindstone, PA
Lines: 53

In article <356@flatline.UUCP> erict@flatline.UUCP (j eric townsend) writes:
>Does your hard drive *pause* while you go from one window to another?
>Mine does.
>
>I thought Unix was multitasking, etc etc.  I didn't think it would
>have to stop HDU access just to change windows.  Am I missing something
>vital>

Another response to this article suggested UNIX "wasn't multitasking" but used
the "sleight-of hand called time-slicing".  (Quotes approximate.)  This poster
may have understood correctly but sure didn't explain it.

Yes, UNIX is definitely multitasking -- but only at the *USER* level.  The
*kernel* is not multithreaded or multitasked in any way.  A UNIX process is
a twin-headed beast:  the process executing in user mode and the process
executing in kernel mode.  A process executing in user mode can be preempted
by an interrupt, but it's my understanding that a process executing in kernel
mode *IS NOT PREEMPTED* -- it must voluntarily give up the CPU.  (Obviously
an interrupt handler is typically invoked at the hardware level, so an
interrupt handler *may* preempt a process in kernel mode, but this is not the
same thing as a context switch!  I.e. an interrupt handler may respond to the
disk controller while a process is executing in the window driver, but when
the interrupt handler returns the window driver will resume and the disk
driver which is to consume the results of the interrupt from the controller
will not be scheduled until the window driver yields.)  All drivers
execute in kernel mode.  When you switch windows the code that does this is
part of the window driver, & thus is definitely executing in kernel mode.  A
piggy driver can definitely shut out other drivers if it's badly written.
comp.unix.microport has been the site of some quite vociferous complaints of
this kind from time to time -- though those problems may have been cleared up
by now.

When you get to talking about drivers and yielding the CPU in kernel mode and
such topics you pretty soon get to the awful Dirty Little Secret of UNIX:  The
UNIX kernel has absolutely NOTHING in the way of internal adult mutual
exclusion mechanisms.  There are only two methods of mutual exclusion that I
know about inside the kernel:  (1) Just plain being careful: reducing the
vulnerability to race conditions by knowing what kernel data structures you're
impacting; (2) masking out interrupts.  Yes boys and girls, this awful thing
is true.  The kernel has no semaphores.  The kernel has no message passing.
All those nifty things you learn in operating systems classes don't happen
inside the UNIX kernel.  A driver writer has to know the interrupt structure
across THE WHOLE MACHINE and when masking interrupts is necessary and when it
isn't.

Of course various rewrites of UNIX don't suffer this opprobrium.  Mach does
have kernel threads.  So will System V.5.  What the internal structure of the
kernel under OSF/ix (or whatever it's called) will be I haven't heard.
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /