Hi Mark,
On Monday 05 October 2009 10:32:12 Mark Rivers wrote:
>
> Either I don't understand your analysis, or I don't agree with it.
>
> Your suggestion is:
>
> int abort;
> int abortOut;
> assign abort to "{P}{R}Abort.VAL";
> assign abortOut to "{P}{R}Abort.VAL";
> monitor abort;
> evflag abortMon;
> sync abort abortMon;
> ...
> ss xpsTrajectoryAbort {
> state monitorAbort {
> when (efTestAndClear(abortMon) &&
> (execState==EXECUTE_STATE_EXECUTING)) {
> ...
> abortOut=0;
> pvPut(abortOut);
> } state monitorAbort
> }
> }
>
> Consider what happens when an external agent sets Abort.VAL to 1.
> The when statement will detect the monitor event, set abortOut=0 and
> call pvPut. That will result in another monitor event, and the when
> statement will execute a second time, again setting abortOut=0 and doing
> the pvPut. In fact this can potentially cause an infinite loop, but
> normally won't because records won't call dbPostEvents if the value has
> not changed?
>
> This double-processing is what Patrick is trying to avoid. It can be
> avoided by detecting that the monitor callback is for the same value
> that was written with the previous pvPut, or by using Tim's database
> logic.
My impression was that Patrick was seeing the event flag being set *twice* by
an update that his put caused, which I didn't think was quite the same thing
that you described. I admit I didn't look at your example very closely and
you're right that in your particular case you would want to keep the test of
the abort variable in the when condition. Patrick certainly needs to make
sure that his sequence program can handle the reflections caused by its own
put operations.
However I don't think this invalidates my main point, which is that using the
same variable for both monitoring a PV and putting values to it is open to
strange things happening due to a possible race condition. I suspect that's
why you saw a difference in behavior between R3.13 and R3.14.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
- Replies:
- RE: state notation code flags Mark Rivers
- References:
- state notation code flags Patrick Thomas
- Re: state notation code flags Andrew Johnson
- RE: state notation code flags Mark Rivers
- Navigate by Date:
- Prev:
RE: Channel access dynamic array subscription update element count Jeff Hill
- Next:
Re: Channel access dynamic array subscription update element count Andrew Johnson
- 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: state notation code flags Mark Rivers
- Next:
RE: state notation code flags Mark Rivers
- 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
|