[gclist] A problem with the Baker treadmill.

[David Petrie Stoutamire]

James McCartney wrote:
> >I can confirm that writing your own spinlocks is the
> >right thing to do.
> 
> 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.

This is true for timesliced, real time processes.  However, by
default threads in Solaris aren't time sliced - they don't get
preempted until some synchronization event, signal, or process
swap occurs.  Of course they could be, but empirically they just
aren't for Sparcs under Solaris 2.{3,4,5}.

If they were, there are other, weirder tricks that could be played,
like catching the LWP signal that actually causes preemption.

The devil is in the details, and I agree the tradeoffs can be made
to go the other way.  Here are some microbenchmark results for a 4
cpu SS10 @ 40Mhz, times in usecs:

   Uncontested lock                   1.33
   Uncontested semaphore              6.29
   Uncontested spinlock               0.31
   Lock ping-pong                   256.06
   Semaphore ping-pong              254.04
   Spinlock ping-pong                 2.03

These are spinlocks with exponential backoff to avoid congesting 
the bus.  (I realize these numbers don't deal with my claim about
preemption not mattering, but I happened to have them handy.)

   - Dave

-- 
David Stoutamire
http://stoutamire.com/david