RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields

["Mooney, Tim M." <mooney@aps.anl.gov>]

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 (mooney@aps.anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Zhang, Dehong [dhzhang@slac.stanford.edu]
Sent: Friday, April 29, 2016 6:12 PM
To: tech-talk@aps.anl.gov
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