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

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