Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!msuinfo!rudolf.nscl.msu.edu!fox
From: fox@rudolf.nscl.msu.edu (Ron Fox)
Newsgroups: comp.realtime
Subject: Re: Spin locks
Message-ID: <1991Jan31.140134.9917@msuinfo.cl.msu.edu>
Date: 31 Jan 91 14:01:34 GMT
References: <133107@<1991Jan22> <3600009@interc>
Sender: news@msuinfo.cl.msu.edu
Reply-To: fox@rudolf.nscl.msu.edu (Ron Fox)
Organization: National Superconducting Cyclotron Lab.
Lines: 36

--
In article <3600009@interc>, prent@interc.UUCP writes:
>Path: >
>
>In the Concurrent multiprocessor implementations, as in a number of
>others, the spinlock technique is almost perfectly efficient due to
>the hardware architecture.  The presumption is only that the
>checking processor really has nothing better to do than wait for the
>resource being locked. 

  This is the key assumption and depending on what you use spinlocks
for it may
or may not be true.  To me a place to use spin locks would be in the
O/S to lock shared
resources such as the process queues, or distributed O/S tables. The
place in this
architecture *NOT* to use spinlocks would be in process level IPC's
because during
the spin, you could get better system wide throughput if you could
schedule someone else to run while waiting for the lock to complete. 
Of course this should not be taken as a blanket statement.  If the
cooperating applications *knows* things about it's partners, or has
special timing requirements for the latency of detecting the release
of the lock (this is comp.realtime after all), then all bets are off
and the actual processor usage profile is less important than the
timing requirements of the application.

> [coherent caching discussion elminated here.. ]

	Ron

Ron Fox                     | FOX@MSUNSCL.BITNET      | Where the name 
NSCL                        | FOX@RUDOLF.NSCL.MSU.EDU | goes on before
Michigan State University   | MSUHEP::RUDOLF::FOX     | the quality
East Lansing, MI 48824-1321 |                         | goes in.
USA