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: Marty Kraimer <mrkraimer@comcast.net>
To: tech-talk@aps.anl.gov
Date: Fri, 21 May 2010 10:51:00 -0400

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.



Note that long long ago it was assumed that incrementing a 32 bit integer was an atomic operation As I recall this was true on the motoralla 68xxx architecture and was used for locking. I do not remember if base assumed than accessing a double was atomic but I may remember incorrectly. A bug appeared, if I remember correctly it was when the PPC had to be supported, and this assumption was no longer assumed.
By the way, I think arrays are already unsafe on the server!

Ouch!



I think this is wrong. Jeff and I thought about these issues really really hard a long long time age (early 1990s). Feel free to see if we made a mistake but please prove a problem rather than just guessing.


Note that rsrv (The CA server for the IOC) calls db_get/db_put. These call dbGetFiedld/dbPutField which lock and unlock
For arrays rsrv always does a complete get or put never a partial get/put. Thus array access should be safe.


Marty
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







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
RE: Race conditions in SNL programs Mark Rivers

Navigate by Date:
Prev: Re: Rogue process variables Ralph Lange
Next: Re: genSub to aSub conversion emmanuel_mayssat
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 Mark Rivers
Next: areaDetector R1-6 released Mark Rivers
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 ·