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.033030.22638@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:30:30 GMT
Lines: 33

From: Michael_Young@transarc.com
To: rchen@m.cs.uiuc.edu
Subject: Re: interrupt and simple_locks

> 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. ...

If an interrupt handler may try to take that latch, interrupt
protection is required.  In your example, the scheduling
system needs to take the latches in question at timer
interrupt time, so those scheduling latches require protection.
Many objects (e.g., in the VM system) are never handled at
interrupt level, and therefore don't need protection.

> It is true that an interrupt may arrive after an object has
> been locked, but that should not cause any harm, right?

Wrong.  The interrupt handler may try to take the latch.  If the latch
was already taken, the interrupt handler would spin forever.
Interrupts cannot be rescheduled the way normal threads can be.

The network service thread (in Mach 2.5 at least) is an example of how
to get around this problem.  The interrupt handler queues work for a
real thread.  The real thread can get rescheduled, so it can take
latches.  Those latches don't need interrupt protection.

Feel free to repost this; I cannot post directly from here.