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
|