Xref: utzoo unix-pc.general:2461 comp.sys.att:5837 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!bpa!manta!cgh!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: <451@amanue.UUCP> Date: 14 Mar 89 06:27:03 GMT References: <356@flatline.UUCP> <450@amanue.UUCP> <1211@lemuria.usi.com> Reply-To: jr@amanue.UUCP (Jim Rosenberg) Organization: Amanuensis Inc., Grindstone, PA Lines: 64 In article <1211@lemuria.usi.com> dpw@lemuria.UUCP (Darryl P. Wagoner) writes: >}In article <450@amanue.UUCP> jr@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! /