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  <20092010  2011  2012  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  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: back propagating error states
From: Andrew Johnson <[email protected]>
To: "Leicester, PJ (Pete)" <[email protected]>
Cc: [email protected]
Date: Wed, 22 Apr 2009 13:41:26 -0500
Hi Pete,

On Wednesday 22 April 2009 12:14:30 Leicester, PJ (Pete) wrote:
> Thanks Andrew and Stephanie. The addition of the CP flag does work as
> far as I can see. It certainly seems ok from edm.

Note that your whole chain actually gets processed twice if the longout fails 
or changes its alarm severity for some other reason, but that's probably not 
a problem.

> My one concern now is if I have a client using put callback to change
> the mbbo record will it see the error state in the mbbo record or is the
> callback complete before the SDIS MS CP updates the mbbi's error status.

That client would be doing a ca_put_callback(), which will complete as soon as 
the longout record finishes processing the first time (the CP link would not 
cause that completion to be delayed until the second process, as I mentioned 
above).  However even if it were putting straight to the longout it would 
never be notified in its callback routine that the record had gone into 
alarm.  Therefor the client will need to be monitoring the mbbo for alarm 
severity changes anyway, and the only issue will be that there may be a very 
slight delay between the callback and the monitor from the alarm transition.

> Perhaps there is a race condition here?

I don't think so in practice.  Here's the operation as I see it:

1. CA Client does a put_callback to the mbbo.
2. The CA server sets the VAL field and processes the mbbo, which forward 
links to the calc and then the longout.  Serial output starts.
3. When serial output finishes (and fails) the longout restarts processing 
through the async completion mechanism and sets SEVR.
4. If the new SEVR is different to the old value, recGblResetAlarms() queues a 
CA monitor event via CA to the mbbo's SDIS CP link.
5. The longout process routine calls recGblFwdLink(), which tells the 
put-notify mechanism that all operations on this record have finished.
6. The put-notify code tells the CA server that the original put_callback has 
completed, which tells the CA client.
7. The dbCaLink CA client gets notification of the event on the SDIS CA link 
and causes the mbbo record to be processed.
8. Repeat steps 2 through 5.

As long as the longout serial output operation fails both times the value of 
SEVR will not change the second time, so step 7 will not be triggered and the 
loop will stop.  The only issue would be if the serial operation succeeds on 
the repeat, which would trigger another round of steps 2 through 5.

With regard to Staphanie's point, I don't know what the Streams device support 
does when a serial device comes back online.  If it causes all its records to 
process then this would actually trigger the processing chain, causing the 
new value to be output and the alarm status of the mbbo to be cleared.  I'm 
guessing that's what you'd want to happen anyway though.

HTH,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

References:
RE: back propagating error states Leicester, PJ (Pete)

Navigate by Date:
Prev: RE: back propagating error states Allison, Stephanie
Next: Re: Priorities of epicsThreads on Linux jun-ichi.odagiri
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: back propagating error states Allison, Stephanie
Next: RE: back propagating error states Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·