EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Fwd: Sequencer bug?
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 26 Feb 2010 00:20:28 +0100
On Donnerstag, 25. Februar 2010, Tim Mooney wrote:
> On 2/25/2010 7:43 AM, 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? Could the compiler warn us about
> > that? Or is this too restrictive?
>
> Wrong take-home message, though.  If you had written this in C,
> your first thoughts would probably have been something like this:
>
> "Hmmm... two tasks; shared resource; better implement a mutex"

Well, actually I would assume that with a single 'int' variable, assignment 
and test for true/false are atomic operations, at least on the architecture 
where my program is supposed to run. Anyway, this was not the problem: 
access to the state variable is atomic just fine, it's just that event 
(wake up) and test for the value are not. This is why two event flags, or 
even two state variables assigned to the same PV work fine. As would two 
semaphores for the C program.

> and your life would have been less eventful.  (Sorry for the pun.
> Here's another: this is a very old tale with a context switch.)
>
> I've stabbed myself with exactly this blade more times than I can
> count, in every programming language I've ever used.

I think if you had restricted yourself (or your language did) to message 
passing with copy semantics (not necessarily implementation) a la CSP 
(http://www.usingcsp.com/cspbook.pdf), that is, avoid explicit shared 
state, your life would have been a good deal less eventful, though of 
course not completely boring ;-)

> I think the take-home messages are simply that SNL is not magic,
> and that multitasking event-driven software is hard to get right.

I absolutely agree. It's just that in this case the language forces me to 
use shared variables instead of message passing *even though the underlying 
mechanism of synchronization is basically message oriented*.

My particular problem was directly caused by the (forced) separation (via 
global shared variables) between the synchonization (monitor event, pvPut) 
and access to the value transported. This is something that has bugged me 
ever since I learned about SNL. And it could be fixed by making a number of 
language-level changes (the underlying implementation of the sequencer and 
the generated C-code could remain almost the same):

 o Allow variables local to a state or a state-set. Forbid or at least
   discourage global variables. (Global constants are of course fine and
   declaring them should be more directly supported.)

 o All communication between state-sets should be via PVs or event flags
   (what was the reason, again, not to call them semaphores?) which both may
   be declared at the top-level. One would need some sort of pv or channel
   data type that gets bound to a PV (at the top-level or local to a state
   set) in a way similar to the current 'assign..to' clause.

 o Allow access (write or read) to a PV object only with a procedure call
   that gets resp. returns a value; events from monitored PVs store their
   payload into a local variable that must be explicitly bound in the state
   declaration.

> Compilers can't really help with stuff like this, because you
> could have the same problem by writing to X and monitoring some
> other PV, Y, that gets changed as a result of the write to X.
> What's really pernicious is the case in which X modifies Y
> via a CA link, or via the reply to a serial device.  In these
> cases, the race condition is moved out in time so you almost
> never can find it in testing.

That sounds bad, but are you sure we are talking about the same class of 
problems here?

Cheers
Ben

Replies:
Re: Fwd: Sequencer bug? Andrew Johnson
References:
Re: Sequencer bug? Benjamin Franksen
Re: Fwd: Sequencer bug? Benjamin Franksen
Re: Fwd: Sequencer bug? Tim Mooney

Navigate by Date:
Prev: RE: asyn R4.12 and streamdevice R2.4 Mark Rivers
Next: Re: Fwd: Sequencer bug? Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Fwd: Sequencer bug? Tim Mooney
Next: Re: Fwd: Sequencer bug? Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·