Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 25 Feb 2010 12:28:30 -0600

I think every one of my state programs does pvPut and monitors on the
same PV.  Generally they do the following:

- Put a monitor and an event flag on a PV which is a bo or busy record
int     build;       assign build        to "{P}{R}Build.VAL";
evflag buildMon;       sync build        buildMon;

- Have a when clause like the following:

  when(efTestAndClear(buildMon) && (build==1)) {
        } state build

 - Set boVal back 0 to, do a pvPut

   /* Clear build command, post.  This is a "busy" record, don't want
    * to do this until build is complete. */
     build=0;
     pvPut(build);

The check for build=1 is needed because the event will also fire as a
result of the pvPut of the boVal back to 0.  That behaviour actually
changed in some version of the sequencer several years ago (previously I
could avoid the event flag being set as a result of the pvPut in the SNL
program).

I don't see anything wrong with the above logic, and I hope I don't a
bunch a warnings in a new version of the sequencer.  Is the problem that
was recently discussed limited to the case of multiple state sets
monitoring the same PV?

Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Thursday, February 25, 2010 12:02 PM
To: [email protected]
Subject: Re: Fwd: Sequencer bug?

On Thursday 25 February 2010 07:43:51 Benjamin Franksen wrote:
>
> It remains to draw practical conclusions for how to avoid such race
> conditions in SNL code. Should we generally be wary of pvPut and
monitor to
> the same state variable?

That is certainly my recommendation, since doing so avoids having to
think 
through the possible consequences for the state program.  Thanks for
posting 
your detailed analysis, I think it shows that the issue is a very subtle
one.

When I've suggested not doing that in the past some people have said
that they 
use the technique without problems, but I suspect that they could still
suffer 
from it under some circumstances, they just haven't seen it /yet/ (or
maybe 
their application doesn't fail spectacularly when it happens).

> Could the compiler warn us about that? Or is this too restrictive?

If someone wants to develop the code to add that as a warning I would be
in 
favour of merging it.  I suspect that it wouldn't be too hard to do,
you'd do 
the check whenever you process a pvPut() call (but I'm not a compiler
writer 
so I could be wrong about the difficulty).  As long as it's a warning I
don't 
think it would be too restrictive (C and C++ compilers have a long
history of 
adding warnings as the developers discover more common anti-patterns).

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System