home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / parallel / 1936 < prev    next >
Encoding:
Text File  |  1992-08-18  |  1.7 KB  |  41 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gumby!destroyer!gatech!hubcap!fpst
  3. From: bernardl@cs.Stanford.EDU (Bernard Lee)
  4. Subject: Re: Is the overhead of spin lock acquisition always significant?
  5. Message-ID: <1992Aug19.063703.3904@leland.Stanford.EDU>
  6. Sender: news@leland.Stanford.EDU (Mr News)
  7. Organization: DSG, Stanford University, CA 94305, USA
  8. References:  <1992Aug18.111938.19628@hubcap.clemson.edu>
  9. Date: Wed, 19 Aug 92 06:37:03 GMT
  10. Approved: parallel@hubcap.clemson.edu
  11. Lines: 28
  12.  
  13. In article <1992Aug18.111938.19628@hubcap.clemson.edu>, Ian Heavens <ian@spider.co.uk> writes:
  14.  
  15. |> This issue becomes important because multiple-reader/single-writer
  16. |> locks are much more convenient to use, and reduce contention, at
  17. |> a cost of increasing the overhead (three times that of a mutex lock?).
  18. |> 
  19. |> Are their cache consistency or other reasons to inflate the overhead
  20. |> of testing and setting a memory location?  What have I missed?
  21. |> 
  22. |> Can someone suggest a rough equivalent for a spin lock acquisition in
  23. |> terms of (some arbitrary mix of) instructions execution, where both 
  24. |> instruction and data fetch are cache hits?
  25.  
  26. Try running some industrial CFD applications with writable global data 
  27. (like the Barnes-Hut algorithm) on 100's of processors.  You will literally
  28. see the machine comes to a halt...
  29.  
  30. Our experience on the Stanford DASH machine is that, when simulating
  31. iPSC/860 functions such as those global gadd or gXXX functions, the 
  32. contention can get so bad that a single instruction on a vector machine
  33. can turns into 20,000+ instructions, all because of lock-spinning.
  34. We end up having to redesign the algorithm.
  35.  
  36. It all comes down to how "real" your application is.
  37.  
  38. Regards,
  39.   Bernard Lee, Stanford CS Dept.
  40.  
  41.