Question about windows and processor time (3b1)

[Jim Rosenberg]

In article <1211 at lemuria.usi.com> dpw at lemuria.UUCP (Darryl P. Wagoner) writes:
>}In article <450 at amanue.UUCP> jr at amanue.UUCP (Jim Rosenberg) writes:
>}The kernel has no semaphores.  The kernel has no message passing.
>
>It does have message passing.  It couldn't work without them.  The sleeping
>on a address is a example of message passing.

Oh boy.  This could easily get into hair splitting.  You are perfectly right
to take me to task for not mentioning that the kernel does use sleep/wakeup
extensively.  It occurred to me shortly after I made my posting that I was
guilty on this point.  **However** if you believe sleep/wakeup is equivalent
to message passing then I believe you are mistaken.  See Tannenbaum for a full
discussion of this.  Briefly, the following three mutual exclusion methods are
more or less equivalent:  (1) semaphores (2) monitors (3) message passing.
Sleep/wakeup is *NOT* generally equivalent to these three.  The problem is
that a wakeup sent to a process already awake is lost.  The only real way
around this is to have a counter of pending wakeups.  There is a name for
this:  it's called a semaphore!

My main argument still stands.  It's my understanding that sleep/wakeup is
used by the kernel to manage resources which are *NOT AVAILABLE*.  E.g.  if a
block is needed in the buffer cache and none is available the process will
sleep until one is available.  That is *NOT THE SAME THING* as saying that the
buffer cache as a data structure is *PROTECTED AGAINST CORRUPTION* by
sleep/wakeup.  I believe in fact this just not the case.  I believe in fact
there is *no* general mechanism by which critical regions of code in the
kernel protect data structures against corruption that would occur from being
arbitrarily reentered except the two I mentioned:  (1) Knowledge and care that
a race condition is in fact not possible; (2) disabling interrupts.  I would
be *DELIGHTED* to be proven wrong on this point.  It is exactly because
wakeups can be lost that they are dangerous to use for mutual exclusion.
Tannenbaum gives an example of such a race condition.

Now answer me one question.  If the kernel is so hunky dory inside, just why
does a driver writer have to know about spl()??  (To know *A LOT* about spl()
in fact.)  In my opinion a driver writer should only need to know how to mask
interrupts for the device being driven.  I believe it is quite correct that
there are many many drivers which *must use spl()* to prevent corruption of
kernel data structures because the kernel provides nothing better.  I'd be
amused to see how long your kernel you run would last if all the spl()'s in
all the drivers you use were excised in favor of sleep/wakeups.  I bet you
wouldn't be amused at all.

And now a word for those who think this is all nit-picking and doesn't matter.
It does matter, it matters a lot.  The issues we're talking about are deeply
related to why driver writing is so often described as a black art.  The fact
that it's a black art costs us all money.  It means that hardware released for
the DOS market takes months or years to make it to the UNIX market -- if it
makes it at all -- because the effort of writing a UNIX driver is so much more
tricky than writing a DOS driver.  Not to mention that porting drivers is
often far more thorny than porting user code.  The lack of a sane well defined
driver interface cuts down on the variety and timeliness of hardware available
in the small-system UNIX market.  This is important, dammit!!

System V.5 will have kernel threads and all that neato stuff.  Mach has
message passing.  V.4 supposedly has a formalized driver interface:
***Hooray!!!***.  Who knows what will be in OSF/ix.

All of which means el squatto to us orphan 3b1ers.  Sigh.
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /