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
<2009>
2010
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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|