Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: <4813@lectroid.sw.stratus.com>
Date: 4 Apr 91 18:10:13 GMT
References: <1991Apr3.184610.12580@m.cs.uiuc.edu> <4799@lectroid.sw.stratus.com> <1991Apr4.035548.25439@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: 29

In article <1991Apr4.035548.25439@m.cs.uiuc.edu> rchen@m.cs.uiuc.edu (Rong Chen) writes:
:dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber) writes:
::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.
:
:Why do we want the interrupt handlers to acquire locks?  I thought
:the interrupt handlers should always be executed from begin to end
:without any complications.  Usually the handlers will only change
:some volatile data structures in the kernel space.  Shouldn't we
:limit interrupt interface only between kernel and hardware, and
:spin-locks only among kernel objects?
:

Just out of curiosity, how do you suggest that the interrupt handler
"change the volatile structure" in kernel space in a multiprocessor
environment when there are other threads of control trying to do the
same thing?

:-Rong Chen
: Department of Computer Science
: University of Illinois at Urbana-Champaign


--

Dan S.