Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!caen!uwm.edu!lll-winken!taurus!gate.ready.com!gate.ready.com!buz From: buz@ready.com (Greg Buzzard) Newsgroups: comp.os.mach Subject: Re: interrupt and simple_locks Message-ID: <1991Apr5.053703.21181@ready.eng.ready.com> Date: 5 Apr 91 05:37:03 GMT References: <1991Apr3.184610.12580@m.cs.uiuc.edu> <4799@lectroid.sw.stratus.com> Sender: buz@ready.eng.ready.com (Greg Buzzard) Reply-To: buz@ready.com (Greg Buzzard) Distribution: comp Organization: Ready Systems Lines: 50 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. Yeowww... If the non-interrupt thread is always the reader and the interrupt level code is always the writer it's pretty easy -- one reads (only) the tail pointer and updates the head, the other does the converse (this assumes you're willing to directly share data and that you're willing to add some low-level intra-kernel signalling mechanism that the interrupt level code can use). I agree with Bill Bolosky, this is degenerating away from a Mach specific discussion. I seem to be getting the keen sense that this group has a pretty parochial focus and since I don't want to get into a wee wee contest with anyone :-) I'll save my "abstract" thoughts on the general issues involved on this subject for some other audience... after one final comment. :-) As for the cost of multiple context switches, if waiting on a lock is appropriate w.r.t. your overall system and you know that the lock wont be held for *too* long, then by all means do it. If your system can't tolerate this (possibly non-deterministic) wait, then look at the costs associated with other alternatives, they do exist... I didn't mean to rile anyone I was just viewing the problem from a substantially different perspective, I'll just sit back and observe. :-# -- Greg Buzzard internet: buz@eng.ready.com Ready Systems 470 Potrero Ave. phone: 408/736-2600 Sunnyvale, CA 94086 -- Greg Buzzard internet: buz@eng.ready.com Ready Systems 470 Potrero Ave. phone: 408/736-2600 Sunnyvale, CA 94086