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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: state notation code flags
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: "Andrew Johnson" <anj@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Mon, 5 Oct 2009 12:14:24 -0500
> 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

And I think he only saw 2 updates if he used the SYNC keyword, not with
the default behavior.

> 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.

I don't think I have to invoke a race condition to explain what I
observed on 3.13.

On 3.13
    pvPut(pv)
    efClear(pvEventFlag)

always cleared the event flag, i.e. I did not receive any further events
due to reflection of that pvPut.  I believe I would have observed the
same thing even if, as you suggest, I had used a different SNL variable
for the monitor and the put. It seemed like the monitor event due to the
pvPut had been received by the time the efClear was called, whereas that
seems not to be true in 3.14.

Mark



-----Original Message-----
From: Andrew Johnson [mailto:anj@aps.anl.gov] 
Sent: Monday, October 05, 2009 11:17 AM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov; Patrick Thomas
Subject: Re: state notation code flags

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



References:
state notation code flags Patrick Thomas
Re: state notation code flags Andrew Johnson
RE: state notation code flags Mark Rivers
Re: state notation code flags Andrew Johnson

Navigate by Date:
Prev: Re: Channel access dynamic array subscription update element count Michael Abbott
Next: Re: Driver for Acromag IP341 Kate Feng
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: state notation code flags Andrew Johnson
Next: Re: state notation code flags Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·