Path: utzoo!attcan!uunet!cs.dal.ca!nstn.ns.ca!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.internals
Subject: Re: Help with 4.3 mod to kill uninteruptable procs.
Message-ID: <1991Feb27.105436.1554@thunder.mcrcim.mcgill.edu>
Date: 27 Feb 91 10:54:36 GMT
References: <1991Feb19.001941.29928@lynx.CS.ORST.EDU> <5583@awdprime.UUCP>
Organization: McGill Research Centre for Intelligent Machines
Lines: 30

In article <5583@awdprime.UUCP>, tif@doorstop.austin.ibm.com (Paul Chamberlain) writes:
> In article <5558@awdprime.UUCP> jfh@greenber.austin.ibm.com (John F Haugh II) writes:
>> A typical sleep loop looks something like

>>	while (some_status & some_busy_flag)
>>		sleep (&some_status, PRI_O_MINE);
>>	some_status |= some_busy_flag;

> John, perhaps it obvious, but I've seen several places that neglect
> to do this right, and I don't want it to become anymore widespread.
> Unless you like drivers that hang sometimes, this is the way it
> should be:

> 	DISABLE_INTERRUPTS;
> 	while (some_status & some_busy_flag)
> 		sleep (&some_status, PRI_O_MINE);
> 	ENABLE_INTERRUPTS;
> 	some_status |= some_busy_flag;

I would tend to move the enable after the bit set.  I think at present
it doesn't make any difference, but only because kernel code can't be
preempted, except in a limited way by interrupts, and the interrupt
handler never sets or clears the busy bit.  If either of these changes,
you'll be glad you have the enable after the setting of the busy bit!

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu