Re: "spinlock" API

[Andrew Johnson <anj@aps.anl.gov>]

Hi Michael,

On 2012-06-12 Michael Davidsaver wrote:
> > To be honest, I'm a little unsure what the performance implications of
> > a spinlock implementation would be when task preemption can't be
> > disabled.

The main thing that worries me is what happens if someone tries to take the 
spinlock from within a signal handler, which is the closest thing to an 
interrupt on most Posix platforms.  If the pthreads implementation uses 
something like green threads and the thread that owns the spinlock is also 
used to execute the signal handler then the result could be a deadlock on some 
platforms.  In that case we'd need to disable signals for that thread while 
the spinlock is locked, using pthread_sigmask().  The test code should check 
that either a signal handler can safely block on a locked spinlock, or that 
the signal is properly locked out while the lock is held.

> Just to be clear, I'm thinking of starvation issues like priority
> inversion which can arise when the OS scheduler does not "know" about
> the locking.

I don't see any difference there to a mutex that hasn't taken the syscall as 
you pointed out, since that's the only way in which the OS scheduler could be 
notified that a thread owns a mutex.  I suspect that some other pthread 
implementations will not be as well optimized as glibc, so if we could provide 
an atomic implementation and do some performance measurement we can pick 
whichever works best on each platform.

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte