[gclist] A problem with the Baker treadmill.

James McCartney james@clyde.as.utexas.edu
Wed, 15 Jan 1997 08:17:36 -0700


At 8:15 PM +1100 1/15/97, Sean Case wrote:
>James McCartney <james@clyde.as.utexas.edu> wrote:

>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.)

On the Be you typically try a test and set and if that fails you
acquire a real semaphore. So the uncontested case is very cheap.
A second and third try might do well in case the lock was held by
another processor.
  However I just found out from Be's engineers that a bug on the 603
requires flushing a cache line to prevent a race condition where
multiple CPUs might think they had a reservation. The 604 doesn't
have this problem. Unfortunately this would seem to make a write
barrier that uses fetch_and_store to log overwritten pointers,
to be rather inefficient.


   --- james mccartney     james@clyde.as.utexas.edu   james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx