Re: RFC: libCom/osi - new spinlock API

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

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.

> 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.

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


<tangent>
Why does each posix epicsMutex object have its own pthread_mutexattr_t object, 
rather than sharing one for all epicsMutex objects we create?  The mutexAttr 
member is only referenced in the Create() and Destroy() functions, and the 
Linux manpage says that it's only used to initialize the mutex anyway so these 
copies are all unnecessary and are bloating the struct epicsMutexOSD.

I guess the question is how to create a shared pthread_mutexattr_t object in a 
thread-safe manner; that could be delegated to the posix/osdThread.c::once() 
function, but epicsMutexOsdCreate should check to make sure it exists and if 
not create, use and then destroy a private copy instead (without trying to 
initialize the shared one, so this doesn't become the double-checked locking 
pattern).  We can't use an atomic variable because on some architectures that 
might need to use an epicsMutex for synchronization...

The same is true of the pthread_condattr_t object in the second implementation 
in the posix/osdMutex.c file BTW.
</tangent>

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