Newsgroups: comp.os.mach
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!rchen
From: rchen@m.cs.uiuc.edu (Rong Chen)
Subject: Re: interrupt and simple_locks
Message-ID: <1991Apr4.035548.25439@m.cs.uiuc.edu>
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
References: <1991Apr3.184610.12580@m.cs.uiuc.edu> <4799@lectroid.sw.stratus.com>
Distribution: comp
Date: Thu, 4 Apr 91 03:55:48 GMT
Lines: 18

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?

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