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