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: Michael Davidsaver <mdavidsaver@bnl.gov>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: core-talk@aps.anl.gov
Date: Mon, 11 Jun 2012 18:31:45 -0400
On 6/11/2012 5:16 PM, Andrew Johnson wrote:
...
Can we design the default implementation to use atomic variables instead of
mutexes, unless there really is no alternative?

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.

On a workstation OS the act
of taking or releasing a mutex always requires a context switch, whereas an
atomic operation does not.

Is this true? I thought that a syscall was required, but that the full context switch only occurs if the lock is contested.

http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_mutex_lock.c#l44

Spin-lock operations are supposed to be lighter
than a mutex ones on SMP, and that aspect of your suggestion is bothering me.

Maybe this should be called something other than "spinlock"?

What I want is something which allows for granular locking and is safe to use from an ISR (when applicable). A spin lock is the only primitive I know of which can do this in a RT or kernel environment. Outside of this environment I don't care if it sleeps or not (I can't prevent this anyway).

I'm also depending on the recursive behavior of both epicsMutex and epicsInterruptLock.

Does this seem like an unusual use case?

Michael


Replies:
Re: "spinlock" API Michael Davidsaver
References:
"spinlock" API Michael Davidsaver
Re: "spinlock" API Andrew Johnson
Re: "spinlock" API Michael Davidsaver
Re: "spinlock" API Andrew Johnson

Navigate by Date:
Prev: Re: "spinlock" API Andrew Johnson
Next: Re: "spinlock" API Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: "spinlock" API Andrew Johnson
Next: Re: "spinlock" API Michael Davidsaver
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 ·