g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: "spinlock" API
From: Andrew Johnson <anj@aps.anl.gov>
To: core-talk@aps.anl.gov, mdavidsaver@bnl.gov
Date: Tue, 12 Jun 2012 12:02:15 -0500
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

References:
"spinlock" API Michael Davidsaver
Re: "spinlock" API Michael Davidsaver
Re: "spinlock" API Michael Davidsaver

Navigate by Date:
Prev: Re: "spinlock" API Michael Davidsaver
Next: timer delay compensation Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: "spinlock" API Michael Davidsaver
Next: timer delay compensation Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·