[gclist] A problem with the Baker treadmill.

[Hans Boehm]

On Jan 14, 11:36am, James McCartney wrote:

> It doesn't matter if the lock is only for a few instructions if the
> scheduler decides your time slice is up at that moment.
> If you are trying to do anything real time on a multitasking system
> you can't afford a spin lock. If a suspended thread holds the lock
> then you will wind up spinning for your entire CPU time slice.
> The only place where I could see using a spin lock would be on
> a multiprocessor system where each processor runs single threaded.
>
As others have pointed out, you want to use a spin lock that yields
after some number N of cycles.  You may even want to dynamically adjust
N depending on your best guess as to whether you are being scheduled
against the thread holding the lock.  (If busy-waiting succeeded a
millisecond ago, you're probably not.  There is an appropriate spin-lock
implementation in the SGI STL, http://www.sgi.com/Technology/STL, in
alloc.h.  This is admnittedly not were it belongs.)

More generally, it seems to me that this is one case in which solutions
with good real-time properties don't behave all that well in the
expected case.  If you want the lock to behave fairly, so that you
get some guaranteed response from each thread, you should
hand off the lock to a waiting thread when you release it.  But if
you have more active threads than processors, that typically forces
extra contex switches, very often one per lock acquisition.  The result
may be fair, but only that you spend all your time in the scheduler and
nobody gets anything done.

At least in cases in which they aren't held for too long, I've found spin
locks to be at the opposite extreme.  They perform well, but admittedly
not predictably.

Hans

Standard disclaimer ...

-- 
Hans-Juergen Boehm
boehm@mti.sgi.com