EPICS Controls 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  2010  2011  2012  2013  2014  2015  <20162017  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  <20162017  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:

1. is it true that all the "process" functions of all the records within one IOC share ONE

    thread?  So we should avoid having within one IOC multiple records which have

    extensive calculations (including memory copying) in their "process" functions?


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.

2. the CA server uses another thread(s) with lower priority for broadcasting to "camonitor"s

    and replying to "caget"s?  Is this thread(s) shared by all the records?


 Channel Access uses a pair of threads (one for each direction) per remote client.

3. does the CA server have its own buffers for each field/broadcasts?  Or it shares the same

    memory locations with the records?


    Here the answer seems to be "yes" for scaler fields, BUT "no" for string or array fields


Correct.
Scalar fields are put in the per-client-queue as values, arrays and strings are put in the queue as pointers.

    does this mean that there is NO guarantee that string/array fields will have the correct

    time stamps?


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.

4. what happens when the CA server replies to "caget"?  Do we also have this "scalers are

    buffered, but string/arrays are not" issue?  Or "nothing is buffered, but takes whatever

    is available (old data and new time stamp, or new data and old time stamp etc) at that

    particular moment?


The answers to "caget" use the same mechanism: scalars are always consistent, arrays/strings may have newer data under congestion.

5. for completeness, a real dumb question: if I don't, or haven't have time yet to, call "db_post_event",

    the "camonitor"s will certainly not get anything, but can a "caget" still get the current value?


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.

Sorry for all these dumb questions.  More and more we are using EPICS in a daq fashion.

From the above document, I see a great danger in correctly assigning time stamps to

string/array data.  Without patching EPICS base, it seems there is no lock/mutex will help

to close this hole.  Hopefully it is me who missed something.


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


Replies:
RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Mark Rivers
Erratum: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Ralph Lange
Re: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Michael Davidsaver
References:
Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Zhang, Dehong
RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Mooney, Tim M.
Re: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Till Straumann
Re: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Zhang, Dehong

Navigate by Date:
Prev: Re: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Zhang, Dehong
Next: RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Zhang, Dehong
Next: RE: Lock/Mutex to prevent "caget" from cutting in between updating multiple fields Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·