EPICS Re: RFC: libCom/osi - new spinlock API

Experimental Physics and Industrial Control System

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024	Index	2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: RFC: libCom/osi - new spinlock API
From:	Ralph Lange <[email protected]>
To:	EPICS Core Talk <[email protected]>
Date:	Thu, 18 Oct 2012 10:34:09 -0400

On Wed Oct 17 2012 18:53:56 GMT-0400 (EDT), Andrew Johnson
<[email protected]> 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 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
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 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024