Gentlemen,
On Saturday 03 October 2009 08:05:37 Mark Rivers wrote:
>
> What is it you are trying to do? You are doing both pvPuts and looking for
> external changes to the same PV?
>
> If so, then one solution is to ignore events which correspond to the value
> that your SNL program set with pvPut, and only act on events with values
> that must have been done by some external agent. Here is an example from
> one of my programs:
> int abort;
> assign abort to "{P}{R}Abort.VAL";
> monitor abort;
> evflag abortMon;
> sync abort abortMon;
> ...
> ss xpsTrajectoryAbort {
> state monitorAbort {
> when ((efTestAndClear(abortMon)) && (abort==1) &&
> (execState==EXECUTE_STATE_EXECUTING)) {
> ...
> abort=0;
> pvPut(abort);
> } state monitorAbort
> }
> }
I believe the issue you are both discussing is a classic case of a race
condition which is caused by doing exactly what Mark discusses. I suspect
it's possible that the monitor callback can occur and change the value of the
abort variable above in between the lines abort=0 and pvPut(abort), but even
if that's not possible it is still causing the problems that Patrick is
seeing. It is unfortunate that the design of the SNL language makes this
possible, and it may require some major surgery to fix this in the
implementation.
However there is an easy solution, which I'm pretty sure will fix Patrick's
issue: Add a second variable pointing to the same PV which is not monitored
and is used only to do the pvPut operations. Copying Mark's example, I've
added the abortOut variable and removed the test of the abort value from the
when() condition, although it's possible that you might still want that.
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
}
}
If you adopt this model, you're never changing the value of the abort variable
yourself, and I think you'll find that the result will only set the event flag
once, when your put value makes its way back to you via the monitor.
I suspect it would be a good idea to try and get the the SNL compiler to issue
a warning whenever it sees someone calling pvPut() on a variable which has a
monitor on it, since this is IMHO an unsafe practice.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
- Replies:
- RE: state notation code flags Mark Rivers
- Re: state notation code flags Benjamin Franksen
- References:
- state notation code flags Patrick Thomas
- Re: state notation code flags Patrick Thomas
- RE: state notation code flags Mark Rivers
- Navigate by Date:
- Prev:
Re: EPICS Python client application survey Michael Abbott
- Next:
RE: Channel access and ca_element_count Jeff Hill
- 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
|