wakeup() race condition. (theory)

Chris Torek chris at mimsy.UUCP
Sat Nov 26 15:07:35 AEST 1988


In article <1974 at van-bc.UUCP> sl at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.unix.xenix mailing list