Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!udel!rochester!bolosky From: bolosky@cs.rochester.edu (Bill Bolosky) Newsgroups: comp.os.mach Subject: Re: interrupt and simple_locks Message-ID: <1991Apr5.022807.13572@cs.rochester.edu> Date: 5 Apr 91 02:28:07 GMT References: <4813@lectroid.sw.stratus.com> <1991Apr4.225931.20534@ready.eng.ready.com> Distribution: comp Organization: Computer Science Department University of Rochester Lines: 31 In article mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: >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 You could always force the non-interrupt thread that reads the queue to run on the processor on which the interrupts happen, and use interrupt masking! This, of course, is just what you had wanted to avoid in the first place (having interrups masked), requires an extra context switch per interrupt, and requires that you have some kind of thread sitting around just to handle these queue entries. Hardly among the best ideas I've heard recently. So...remember to mask those interrupts before grabbing a lock! Bill PS. Does this really belong on comp.os.mach? It's hardly a Mach specific discussion at this point.