Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Tue, 01 Feb 2011 21:27:31 -0600

I probably have a little different take than Jeff.

While giving the user of 'epicsEventWait()' a 'bad' error status back
offers the opportunity to react to an error
it also burdens the user because he/she then has to check a return
code to make sure that a seemingly trivial operation suceeds.

E.g., when I take a mutex I don't always want to have to check
a return code. Often, I consider the case of failure when taking a mutex
a fatal error. Either due to a programming error (e.g. an invalid
mutex ID) or lack of system resources. Either way, I consider
the possibility of failure with a need for graceful recovery
marginal and the added effort to implement such a recovery
too expensive. However, I also don't want to just take the mutex
w/o making sure I really own it because that would leave
a critical section exposed. Therefore, I really love
epicsMutexMustLock() (even though it's implementation using 'assert'
is flawed since 'assert' becomes a no-op if you compile with the
symbol NDEBUG defined -- assert should IMHO replaced by cantProceed).

Long story short - I'd suggest to provide two interfaces
epicsEventWait() and epicsEventMustWait().

Regarding the posix implementation I consider the operations of
taking/releasing the mutex associated with the condition variable
of the class 'mustSucceed' since this mutex is entirely 'owned'
by the implementation. If epicsEventWait() returns anything
this should be the return value of 'pthread_cond_wait()'.

-- Till

On 02/01/2011 01:54 PM, Andrew Johnson wrote:

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System