Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!att!bu.edu!transfer!lectroid!bigbootay!dswartz
From: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.os.mach
Subject: Re: interrupt and simple_locks
Message-ID: <4799@lectroid.sw.stratus.com>
Date: 3 Apr 91 19:52:42 GMT
References: <1991Apr3.184610.12580@m.cs.uiuc.edu>
Sender: usenet@lectroid.sw.stratus.com
Reply-To: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Distribution: comp
Organization: Stratus Computer, Software Engineering.
Lines: 40

In article <1991Apr3.184610.12580@m.cs.uiuc.edu> rchen@m.cs.uiuc.edu (Rong Chen) writes:
:While I was reading the source code of Mach3.0, I noticed that
:the hardware interrupts, if any, are always turned off before
:a simple-lock is applied to a Mach object.   For example:
:
:	s = splsched();
:	simple_lock(&timer_lock);
:	...
:	simple_unlock(&timer_lock);
:	splx(s);
:
:What's the reason for it?  Shouldn't we do it the other way round?
:Like:
:
:	simple_lock(&timer_lock);
:	s = splsched();
:	...
:	splx(s);
:	simple_lock(&timer_lock);
:
:Since simple-locks are spin locks, they may prolong the period
:of disabling interrupts unnecessarily, in my humble opinion.
:It is true that an interrupt may arrive after an object has
:been locked, but that should not cause any harm, right?
:
:Thanks for anyone who could enlighten me on this issue.
:
:-Rong Chen
: Department of Computer Science
: University of Illinois at Urbana-Champaign

Interrupts must be masked first, since otherwise you have a race condition
where the lock is acquired on call-side and an interrupt comes in before
the spl call.  If the interrupt handler tries to acquire the same lock,
you're stuck, since the only code which can release the lock is the same
thread which is now servicing the interrupt.

--

Dan S.