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: RFC: libCom/osi - new spinlock API
From: Ralph Lange <Ralph.Lange@gmx.de>
To: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Thu, 18 Oct 2012 10:34:09 -0400
On Wed Oct 17 2012 18:53:56 GMT-0400 (EDT), Andrew Johnson
<anj@aps.anl.gov> wrote:
> Hi Ralph,
>
> On 2012-10-17 Ralph Lange wrote:
>> epicsShareFunc void epicsSpinLock(epicsSpinId, epicsSpinKey*);
>> epicsShareFunc int epicsSpinTryLock(epicsSpinId, epicsSpinKey*);
>> epicsShareFunc void epicsSpinUnlock(epicsSpinId, epicsSpinKey*);
>>
>> The epicsSpinKey is used for implementations that need to persist a
>> piece of status data between lock and unlock calls, e.g. intLock().
> Wouldn't it be possible to store that state as a field in the epicsSpin 
> structure itself, protected by the spin-lock?  The Lock() and TryLock() 
> functions would set the field only if/after they succeed, and the value would 
> be read by the Unlock() function which can only be called by the lock's 
> current owner anyway.  Spin-locks cannot be taken recursively, so I think this 
> should be safe and it would save having a separate variable in the calling 
> code.

I agree and will change it that way.

>> At the same time the existing epicsInterruptLock() API would be deprecated.
> Maybe it could be reimplemented using an epicsSpinLock on some architectures, 
> but I think it's pretty heavily used by upgraded vxWorks drivers here so I'd 
> want quite a long deprecation cycle before removing it.

Sure, an eternal deprecation cycle would be fine with me...
Reimplementing epicsInterruptLock() as an epicsSpinLock is a good idea
for vxWorks, where the current implementation would break on SMP
architectures.

> BTW, if pthread_spin_lock() is not implemented, using a native pthread_mutex_t 
> might be lighter weight than an epicsMutex object.

On Posix, yes. (Only slightly though, as the Posix implementation of
epicsMutex uses pthread_mutex_t.)
The Default should be epicsMutex, to make things work on Windows etc.
until specific implementations are in place.

Thanks for your comments!
~Ralph


Replies:
Re: RFC: libCom/osi - new spinlock API Andrew Johnson
References:
RFC: libCom/osi - new spinlock API Ralph Lange
Re: RFC: libCom/osi - new spinlock API Andrew Johnson

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