Xref: utzoo comp.unix.xenix:4003 comp.unix.wizards:12879
Path: utzoo!attcan!uunet!husc6!uwvax!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: Re: wakeup() race condition. (theory)
Keywords: wakeup sleep spl
Message-ID: <14722@mimsy.UUCP>
Date: 26 Nov 88 05:07:35 GMT
References: <455@mrecvax.UUCP> <1974@van-bc.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

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:

1. Change the hardware.

2. Have the polling code test at IPL7.

3. Use the hardware interrupt to schedule a software interrupt, where
   the software interrupt is at a priority not more than IPL5.  If
   appropriate (for serial port efficiency reasons), use a multi-level
   scheme a la DZ `pseudo-dma' on VAXen.  Also (again for efficiency),
   end the hardware interrupt with the sequence

	if (upon_return_ipl_will_be() > IPL5) {
		/* must be running off some higher priority code */
		schedule_software_interrupt(params);
	} else {
		/* just lower priority and go */
		(void) spl5();
		do_tty_interrupt(params);
	}
	return;

   where the software interrupt handler is

	(void) spl5();
	do_tty_interrupt(params);
	(void) splsoftint();

   The spl5()/splsoftint() is necessary iff software interrupts run
   below ipl5 (preferable) rather than at ipl5.  If software interrupts
   always run higher than ipl5, this scheme is pointless.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris