Xref: utzoo comp.unix.xenix:4007 comp.unix.wizards:12886
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!ubc-cs!van-bc!sl
From: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: Re: wakeup() race condition. (theory)
Keywords: wakeup sleep spl
Message-ID: <1977@van-bc.UUCP>
Date: 26 Nov 88 10:52:03 GMT
References: <455@mrecvax.UUCP> <1974@van-bc.UUCP> <14722@mimsy.UUCP>
Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne)
Organization: Wimsey Associates, Vancouver, BC.
Lines: 28

In article <14722@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <1974@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes:
>>This problem does exist when writing drivers under SCO Xenix. ...
>>SCO's line discipline routines protect things at spl5. While serial interrupts 
>>are handled at spl7 and the clock (and all poll routines) run at spl6.
>
>This is grotesque.  There are three `good' ways to fix it:

I agree. I didn't say I liked it. Thats the way that it works on the (almost
current) version of SCO 286/386 that I've been working with.

Unfortunately you're stuck with being unable to change the spl protection in
the line discipline routines, or safely changing the interrupt level of the
clock (and therefore poll) and if you want to ensure that you don't loose
serial interrupts, running them at spl7.

By rights SCO's scheme as designed would work well if they simply raised the
spl level in the line discipline routines to spl6. And you make the
assumption/design criteria the the interrupt routines don't access any
shared data strutures. I.e. for serial drivers only filling/emptying a
private ring buffer. 

In point of fact even as is the end result is pretty bomb proof if inelegant
and slightly inefficent.


-- 
Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532