NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/parallel/1928

Text File | 1992-08-17 | 2.0 KB | 54 lines

Newsgroups: comp.parallel
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!paladin.american.edu!gatech!hubcap!fpst
From: Ian Heavens <[e-mail]>
Subject: Is the overhead of spin lock acquisition always significant?
Message-ID: <[e-mail]>
Apparently-To: [e-mail]
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: redknee.spider.co.uk
Organization: Spider Systems Limited, Edinburgh, UK
Date: Tue, 18 Aug 1992 10:47:12 GMT
Approved: [e-mail]
Lines: 40

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                [e-mail]
Spider Software
Spider Park, Stanwell Street
Edinburgh, EH6 5NG, Scotland        [phone] (Ext 4347)
--