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: | Ralph Lange <[email protected]> |
To: | EPICS Tech-Talk <[email protected]> |
Date: | Sun, 1 May 2016 10:57:05 +0200 |
Hi Dehong,
I'll try to get some of your questions answered. On 01/05/2016 09:55, Zhang, Dehong
wrote:
No. Allocation to threads in the IOC depends on the scan mechanism. Periodic scanning uses one thread for each of the scan periods, I/O Interrupt scanning and the completion phase of asynchronous record processing run from one of the generic callback threads (one per priority), PINI and CP input link related processing use a separate thread, Channel Access uses a thread per client, ... When taking the proper locks, any thread on the IOC may process records.
Channel Access uses a pair of threads (one for each direction) per remote client.
Correct. Scalar fields are put in the per-client-queue as values, arrays and strings are put in the queue as pointers.
Correct. In the congestion case, i.e. when the array data in the record gets updated before an older event is posted, the CA server will send an update to the client that combines the old time stamp (taken from the queue) with the newer data (taken from the record). Note: The EPICS V4 protocol, pvAccess, manages structured data and guarantees updates to be always consistent.
The answers to "caget" use the same mechanism: scalars are always consistent, arrays/strings may have newer data under congestion.
Yes. The difference is basically that in the context of record processing, the scanning thread calls process() which posts events for the fields that were changed, for "caget" it is the CA incoming thread that posts the event for the field that was being asked for.
EPICS 3.15 adds mechanisms that allow things like putting copies of arrays/strings in the queue, helping with consistency. EPICS 3.16/V4 supports structured data on the network, guarantees consistency, and is especially targeted at data acquisition applications. Please consider switching to newer EPICS versions that provide the features you need rather than trying to add patches to a previous version. If you find issues with the newer version, there will be a team of developers interested to improve the code. Patching 3.14, you will basically be on your own. Best regards, ~Ralph |