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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields |
From: | "Mooney, Tim M." <[email protected]> |
To: | "Zhang, Dehong" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Sat, 30 Apr 2016 04:56:24 +0000 |
Hi Dehong,
I don't think the IOC side of a caget is ever going to get any CPU cycles while your record is processing unless you voluntarily give up the processor - for example, by calling asynchronous device support, or by waiting for something (which record support
isn't supposed to do anyway). If all the fields that must be atomic are in the same record instance, I think you're ok.
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab From: [email protected] [[email protected]] on behalf of Zhang, Dehong [[email protected]]
Sent: Friday, April 29, 2016 6:12 PM To: [email protected] Subject: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Hi,
In my custom record, I need to update multiple fields atomically so they stay synchronized -- all updated, or none updated; not a few updated, but a few with the old data. If I use my own mutex, I suspect that "caget" can cut in between the updating and gets, for example, new data with old time stamp, or old data with new time stamp depending on the order of updating.
And I guess "camonitor" would not have this problem because it would be the server pushing the whole set (field itself and time stamp for instance). Is this right?
So to close this hole with "caget", which global lock should I use? dbScanLock?
Thank you, best regards, Dehong
|