🚀 go-pugleaf

I'd like to question one of the sacred cows of spin-lock based shared 
memory multiprocessing: that the number of spin locks acquired should be 
minimised, because the overhead in lock acquisition is significant.

I agree that contention is always significant, and that there are good
other reasons for not having lots of locks (clarity and deadlock
avoidance).  Also, in some applications, the overhead of lock
acquisition may be significant, where the critical sections are
very short and are executed very frequently.

In our application, a TCP/IP protocol stack, the difference between
acquiring 5 and 10 locks on a typical input or output path seems to me
to be insignificant compared to the protocol processing, assuming no
contention for those locks.  

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?

thanks


ian

---
Ian Heavens				ian@spider.co.uk                 
Spider Software
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 555 5166 (Ext 4347)
--