Path: utzoo!attcan!uunet!spool.mu.edu!uwm.edu!src.honeywell.com!klemmer!vestal
From: vestal@SRC.Honeywell.COM (Steve Vestal)
Newsgroups: comp.realtime
Subject: Re: Spin locks
Message-ID: <1991Jan31.113906.26160@src.honeywell.com>
Date: 31 Jan 91 11:39:06 GMT
References: <830@marvin.jpl.oz> <3600010@interc>
Sender: news@src.honeywell.com (News interface)
Organization: Honeywell Systems & Research Center
Lines: 23
In-Reply-To: leong@interc.UUCP's message of 25 Jan 91 13:39:00 GMT
Nntp-Posting-Host: klemmer.src.honeywell.com


In article <3600010@interc> leong@interc.UUCP writes:

>> acceptable KLUGE for small applications, but I sure do not want
>> to design my Real-Time -- Flight Criticle -- Life Saving -- System
>> with the initial flaws of techniques such as spinlocks!

It's not clear to me that spin-locks should be completely ruled out for
reliable real-time systems.  Essentially, multiple processes contending for
the same lock are queued using a random discipline.  I admit this is not as
conceptually nice as being queued using some priority discipline.  However, in
many real-time systems the maximum number of processes that might ever be
queued on a semaphore can be bounded (by some small number).  It would seem
that the total blocking time for any of these processes could be bounded by the
sum of the critical section execution times (plus some delta for the spin-lock
timing).  This may well be a larger blocking time for many of these processes
than could be achieved using, say, a priority inheritance protocol.  Except,
of course, where the priority inheritance lock/unlock times are large relative
to the sum of the critical section and spin-lock times.

Steve Vestal
Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 782-7049                    Internet: vestal@src.honeywell.com