🚀 go-pugleaf

In article <1992Aug19.063703.3904@leland.Stanford.EDU> bernardl@cs.Stanford.EDU (Bernard Lee) writes:
>In article <1992Aug18.111938.19628@hubcap.clemson.edu>, Ian Heavens <ian@spider.co.uk> writes:
>
>|> This issue becomes important because multiple-reader/single-writer
>|> locks are much more convenient to use, and reduce contention, at
>|> a cost of increasing the overhead (three times that of a mutex lock?).
>|> 
>|> Are their cache consistency or other reasons to inflate the overhead
>|> of testing and setting a memory location?  What have I missed?
>|> 
>|> Can someone suggest a rough equivalent for a spin lock acquisition in
>|> terms of (some arbitrary mix of) instructions execution, where both 
>|> instruction and data fetch are cache hits?
>
>Try running some industrial CFD applications with writable global data 
>(like the Barnes-Hut algorithm) on 100's of processors.  You will literally
>see the machine comes to a halt...
>

We had similar problems with SHARP APL running under MVS/XA on a 
TWO (!) processor 309x system, if memory servies(it doesn't, always).
We were using Compare and Swap to implement a race-free linked list
update on a queue. CS has the unfortunate "feechur" of dragging all
other processors to a stop, washing their dishes, clearing their
pipelines, blowing their noses, etc. So, the effect on any but the
most trivial systems was that all processing would hang on the 
CS instructions on all (both) processors. 

The dirty fix is to loop on a counter until the cell-to-be-swapped
looks "OK", then hit the CS once. If it works, fine. If not, go 
count to 1000 and then look at the cell again. This avoids the
synchronize which otherwise paralyzes the system.

Not a swell design for the naive...

Bob

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada