Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 21 May 2010 15:10:07 +0200

Hi Ron

On Friday 21 May 2010, Chestnut, Ronald P. wrote:
> Dear Nesknarf,
> 
> As a person whose favorite hammer is, indeed, SNL, this led me to think
>  about my many programs and whether this has ever been of consequence.
>  The answer is "I think not". I've always used integer values as triggers
>  for state transitions, and compared carefully if the actual value, (and
>  not just a change which triggered a state transition), was important. If
>  some value is critical, I copy it and use the copy, so that I have the
>  monitored value which triggered the transition and not a later monitored
>  value.
> 
> Lots of code looks like:
> 
> When (monitored_value != Stored_value) {
>   Stored_value=monitored_value;
> 
>   Use Stored_value in all code here
> 
> }
> 
> I realize that there is a short time hole in this too, but I can't
>  remember having been bitten by it.

As I said, it is very unlikely to happen in typical programs. But it still 
may happen, and if it does you're screwed.

> One could simply generate a warning if a string or array (or any
>  non-atomic thing -- perhaps a double on some architectures) is not safe;
>  if the programmer knows that only operator-time-scale actions
>  precipitate a new value, this warning could be ignored; if not, change
>  the logic to use an atomic trigger.

You are, of course, free to bury you head in the sand and ignore the 
problem. This won't make it go away, though.

> So my take is that this is a small problem. Finding an elegant solution
>  would be really neat, but not finding it is not a show stopper.

My primary objective is to find a solution that is safe and reliable. I 
think this can be done at a slight cost in runtime performance and 
compatibility.

The runtime cost is that each monitored variable has to be copied from an 
internal buffer, whenever a state set wakes up and checks state change 
conditions and a callback has happened in the meantime.

The cost in compatibility is that changes to a variable (due to monitors) 
will never be seen by the program, except when it waits for events. I think 
this would be acceptable, as I cannot imagine there are lots of programs 
that *rely* on monitored variables changing *during* executution of an SNL 
statement block.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System