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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|