home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / parallel / 1955 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  4. Subject: Re: Is the overhead of spin lock acquisition always significant?
  5. Message-ID: <1992Aug21.121547.5620@hubcap.clemson.edu>
  6. To: uunet!comp-parallel@uunet.UU.NET
  7. Apparently-To: uunet!comp-parallel
  8. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  9. Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  10. Organization: Snake Island Research Inc, Toronto
  11. References: <1992Aug18.111938.19628@hubcap.clemson.edu> <1992Aug19.063703.3904@leland.Stanford.EDU>
  12. Date:     Fri, 21 Aug 1992 00:38:55 -0400
  13. Approved: parallel@hubcap.clemson.edu
  14. Lines: 43
  15.  
  16. In article <1992Aug19.063703.3904@leland.Stanford.EDU> bernardl@cs.Stanford.EDU (Bernard Lee) writes:
  17. >In article <1992Aug18.111938.19628@hubcap.clemson.edu>, Ian Heavens <ian@spider.co.uk> writes:
  18. >
  19. >|> This issue becomes important because multiple-reader/single-writer
  20. >|> locks are much more convenient to use, and reduce contention, at
  21. >|> a cost of increasing the overhead (three times that of a mutex lock?).
  22. >|> 
  23. >|> Are their cache consistency or other reasons to inflate the overhead
  24. >|> of testing and setting a memory location?  What have I missed?
  25. >|> 
  26. >|> Can someone suggest a rough equivalent for a spin lock acquisition in
  27. >|> terms of (some arbitrary mix of) instructions execution, where both 
  28. >|> instruction and data fetch are cache hits?
  29. >
  30. >Try running some industrial CFD applications with writable global data 
  31. >(like the Barnes-Hut algorithm) on 100's of processors.  You will literally
  32. >see the machine comes to a halt...
  33. >
  34.  
  35. We had similar problems with SHARP APL running under MVS/XA on a 
  36. TWO (!) processor 309x system, if memory servies(it doesn't, always).
  37. We were using Compare and Swap to implement a race-free linked list
  38. update on a queue. CS has the unfortunate "feechur" of dragging all
  39. other processors to a stop, washing their dishes, clearing their
  40. pipelines, blowing their noses, etc. So, the effect on any but the
  41. most trivial systems was that all processing would hang on the 
  42. CS instructions on all (both) processors. 
  43.  
  44. The dirty fix is to loop on a counter until the cell-to-be-swapped
  45. looks "OK", then hit the CS once. If it works, fine. If not, go 
  46. count to 1000 and then look at the cell again. This avoids the
  47. synchronize which otherwise paralyzes the system.
  48.  
  49. Not a swell design for the naive...
  50.  
  51. Bob
  52.  
  53. Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
  54. Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
  55. 18 Fifth Street, Ward's Island
  56. Toronto, Ontario M5J 2B9 
  57. Canada
  58.  
  59.