EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: epicsEvent (posix implementation) bug ?
From: "Jeff Hill" <[email protected]>
To: "'Till Straumann'" <[email protected]>, <[email protected]>
Date: Wed, 2 Feb 2011 12:25:54 -0700
Hi Till,

So I agree that a function like epicsMutexMustLock() is only useful for C programmers that prefer not to write error recovery code. I also agree that, given a variety of approaches to design, two functions are needed, and that another reason for the version that returns status is that the C++ programmers will write a wrapper function that converts failure status to an exception. They will have the best situation; minimal extra source code for the error code checking, and also a better potential for recovery. 

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Till Straumann
> Sent: Tuesday, February 01, 2011 8:28 PM
> To: [email protected]
> Subject: Re: epicsEvent (posix implementation) bug ?
> 
> 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:
> > The current Posix implementation of the epicsEvent API contains many
> uses of
> > its local checkStatusQuit() macro to detect and handle situations where
> the
> > OS' pthread routine returns an error — it prints an error message, then
> calls
> > cantProceed() which halts the thread.  In some cases the API leaves
> little
> > choice on what /can/ be done, for example the epicsEventSignal()
> routine
> > returns void, so there is no way to signal a fault up to the caller.
> >
> > In other cases though we can return an error, and I'm working on
> changing some
> > of the internals to just print a warning message and do that instead.
> For
> > example, epicsEventCreate() is allowed to return NULL;
> epicsEventMustCreate()
> > is provided for users who don't want to handle failures themselves.
> >
> > That leaves a few additional cases: epicsEventDestroy() warns but
> continues if
> > either of the pthread_xxx_destroy() routines complain, which seems
> sensible
> > (it may leak memory, but we have reported something).
> >
> > The interesting question (the main purpose of this message) is what to
> do if
> > pthread_mutex_unlock() returns an error at the end of the
> epicsEventWait()
> > routines.  Currently the code uses checkStatusQuit() so will halt the
> thread,
> > unlike the other implementations.
> >
> > A discussion on what the epicsEvent routines should do on getting an
> error
> > from the OS routines is welcome (but Argonne is about to shut down for
> a 12"+
> > snow-storm so don't expect an immediate response from me).
> >
> > - Andrew



References:
epicsEvent (posix implementation) bug ? Till Straumann
Re: epicsEvent (posix implementation) bug ? Eric Norum
Re: epicsEvent (posix implementation) bug ? Andrew Johnson
Re: epicsEvent (posix implementation) bug ? Andrew Johnson
Re: epicsEvent (posix implementation) bug ? Till Straumann

Navigate by Date:
Prev: RE: Trouble with mcaR6-12-4 and EPICS 3.14.12 (cygwin-x86) Mark Rivers
Next: epics 3.14.12 and readline 5.1 Matt Rippa
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: epicsEvent (posix implementation) bug ? Till Straumann
Next: Motor driver for Parker Hannifin ACR series controllers? Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·