Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Mon, 14 Apr 2003 11:03:13 -0600

At 10:52 4/14/2003, Allison, Stephanie wrote:
>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,

Hello Stephanie:

I'm wondering about a similar issue here and found that
epicsMutex has only lock(), unlock()
while epicsEvent has signal(), wait(), wait(double timeout).

My conclusion was:
use epicsMutex and hang in lock() w/o timeout in cases
where you absolutely need a resource and couldn't proceed
after a timeout, so why bother?

For thread synchronization where a wait(timeout) might well
time out in some cases, but you can print an error message
and do something else for a while, use epicsEvent.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System