[gclist] A problem with the Baker treadmill.

[Sean Case]

James McCartney <james@clyde.as.utexas.edu> 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.

Tangentially, the test-and-set instruction on the Univac 1100 interrupts
if it fails to acquire the lock. The scheduler bounces back to your
thread on the first interrupt, then preempts you on the second. This
makes user spinlocks very efficient.

I don't know why nobody else has done this, but you could probably
emulate it by manually yielding on two or three fails in a row. (The
retry is in case the lock was held by another processor; I assume
that the spinlock is only up for a couple of instructions. If you
have to do something more complicated, use a heavier weight lock
guarded by the spinlock.)

Sean Case

---------------------------------------------
Sean Case                  gscase@tpgi.com.au

Code is an illusion. Only assertions are real.