Newsgroups: comp.os.mach
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!mintaka.lcs.mit.edu!mib
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Subject: Re: interrupt and simple_locks
In-Reply-To: buz@ready.com's message of 4 Apr 91 22:59:31 GMT
Message-ID: <MIB.91Apr4201536@geech.gnu.ai.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: Free Software Foundation, Cambridge, MA
References: <1991Apr3.184610.12580@m.cs.uiuc.edu> <4799@lectroid.sw.stratus.com>
	<1991Apr4.035548.25439@m.cs.uiuc.edu> <4813@lectroid.sw.stratus.com>
	<1991Apr4.225931.20534@ready.eng.ready.com>
Distribution: comp
Date: 4 Apr 91 20:15:36
Lines: 14

In article <1991Apr4.225931.20534@ready.eng.ready.com> buz@ready.com (Greg Buzzard) writes:

   Certainly one possibility is to not expect the interrupt level code to
   "change the volatile structure" -- it could queue a request for a
   non-interrupt thread to do it.  If there is a synchronization
   "problem" the onus ought to be on the non-interrupt threads to "do the
   right thing"

Pray tell, how do you want to prevent the interrupt handler and the
thread reading from the queue to avoid clashing with eachother?  You
can move the volatility from one structure to another, but it remains.
Putting it in a queue doesn't solve the problem, it just moves it.

	-mib