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

Subject: RE: Race conditions in SNL programs
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: "Benjamin Franksen" <benjamin.franksen@bessy.de>, <tech-talk@aps.anl.gov>
Date: Fri, 21 May 2010 08:28:32 -0500
> Hm, you could try to prove that it happens. This may be difficult, though.

One way to test that would be with the areaDetector software.  It can generate large arrays (images in waveform records) at a high rate.  The waveform records are I/O Intr scanned whenever a new image arrives.  If this problem occurs CA clients should get images are mixes of old and new data.  I have never actually seen this, but because there is generally a high degree of correlation from image N to N+1 it would not be obvious.  There is a simulation driver which could be modified so that even images were all 0 and odd images were all 255, for example. Then such corruption would be easy to spot in a CA client.

Mark

 




 

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Benjamin Franksen
Sent: Fri 5/21/2010 8:17 AM
To: tech-talk@aps.anl.gov
Subject: Re: Race conditions in SNL programs



Hi Dirk

On Friday 21 May 2010, Dirk Zimoch wrote:
> Locking and/or re-reading might be possible for SNL code accessing the
> variables but what about escaped C-Code? You probably have to take the
> lock before escaping to C but then nobody is allowed to do blocking
> things in that code.
>
> A layer of "shadow variables" might be safe. CA updates the shadow copy
> at any time while the state code executes. Only during the state
> transition and inside pvGet the data is transfered to the "user copy".
> (any back inside pvPut). CA has to be locked out only during these copy
> actions. Of course that requires twice the amount of memory for
> variables plus some time for the additional copy.

Yes. I came to the same conclusion when discussing this with Götz. I think
the additional overhead is the price to pay for correctness.

> Concerning double: On the new PPC 500v2 core it takes indeed two
> assembler instructions to load or store a double. Thus doubles are
> non-atomic.

Ah, thanks for a definite statement.

> By the way, I think arrays are already unsafe on the server!

Ouch!

> If the
> array record processes and updates the array at the same time as it is
> sent on the network by CA, the user gets a half old/hald new array. This
> is because only the pointer to the array is put into the queue for the
> CA thread, not the array data itself. (I am happy if somebody could
> prove me wrong.)

Hm, you could try to prove that it happens. This may be difficult, though.

Anyway, thanks for your input!

Cheers
Ben





Replies:
Re: Race conditions in SNL programs Marty Kraimer
References:
Race conditions in SNL programs Benjamin Franksen
Re: Race conditions in SNL programs Benjamin Franksen
Re: Race conditions in SNL programs Dirk Zimoch
Re: Race conditions in SNL programs Benjamin Franksen

Navigate by Date:
Prev: Re: Race conditions in SNL programs Benjamin Franksen
Next: Re: Rogue process variables Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: Race conditions in SNL programs Benjamin Franksen
Next: Re: Race conditions in SNL programs Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·