🚀 go-pugleaf

In article <MIB.91Apr4201536@geech.gnu.ai.mit.edu> 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.