Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 14 Apr 2003 11:49:04 -0600

We noticed that the efficient mutex primitive provided by POSIX
and win32 do not implement a mutex lock with an arbitrary
timeout. Both OS had a lock with a zero length timeout (a so
called try lock primitive) in their efficient mutex primitive.
Since there is quite a bit of locking in certain parts of base
then the proper selection of an efficient mutex primitive has a
big impact on the overall performance of EPICS.

We could have implemented a high level portable mutex primitive
with a timeout by allocating both a low level mutex and an event
semaphore for each high level mutex. This was tried on one OS as
a proof of principal universal mutex primitive, but in the end it
was decided to drop support for the mutex lock with timeout
feature so that we could realize the performance improvements
associated with the low level mutex primitives while avoiding the
additional overhead associated with the allocation of an
additional event semaphore for each mutex.

So for your situation there are several alternatives:

1) You implement a situation specific try lock loop with a sleep
and a timeout embedded in it. This isn't very responsive to
changes in the mutex state and could fail in situations where
there is a high mutex duty factor. Nevertheless, it *was* decided
that this would be sufficient in the situation surrounding one of
the diagnostics run from the shell that comes with base.

2) We implement two mutex primitives: A low overhead primitive
and a high overhead primitive with a timeout. Hopefully the high
level mutex could be implemented purely in OS independent code.

3) You could also implement some application specific variation
of (2) yourself.

Jeff

> -----Original Message-----
> From: Allison, Stephanie [mailto:[email protected]]
> Sent: Monday, April 14, 2003 10:53 AM
> To: '[email protected]'
> Subject: epicsMutexLockWithTimeout not supported in 3.14.1
> 
> Hello -
> 
> We use two device/driver support packages here at SSRL that
> require
> the functionality of epicsMutexLockWithTimeout which is no
> longer supported
> in 3.14.1.  In ipac, it's only needed by the canRead diagnostic
> routine so I simply
> used the same logic I found in epics base/src/db/dbLock.c which
> does a little
> loop with try/wait.   But in ether_ip, this functionality is a
> key part of the support.
> 
> There was discussion about this in core-talk and a few
> sentences in the 3.14.1
> release notes, but it's not clear the best way to port from
> epicsMutexLockWithTimeout
> (or vxWorks semTake with a non-WAIT_FOREVER timeout) to
> something
> equivalent.
> 
> Any suggestions?  Thank you,
> 
> Stephanie Allison
> SSRL/SLAC

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System