Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 7 Nov 2014 10:10:51 -0600

Hi Lewis,

On 11/06/2014 10:57 PM, J. Lewis Muir wrote:
> Thank you for your very helpful reply.  I understood everything up
> until this last part about calling ca_pend_event.  Why would the main
> thread need to call ca_pend_event at all?  For example, I could imagine
> it might just wait for an EPICS event indicating it should exit (e.g.
> "epicsEventWait(stop_event_id)").

My apologies, while I was writing that part I forgot that you had
enabled preemptive callbacks. If you're using that setting there is no
need to have a thread call ca_pend_event(), but your code does have to
take extra precautions about locking its data structures.

The CA library uses multiple threads internally (each TCP socket that it
opens to a server gets its own pair of threads for example), and
enabling preemptive callbacks tells the library that the application is
prepared for its callbacks to be run from any of the CA library threads
as soon as they are ready to do so. That means you need to think
carefully about the data that the callback routines are accessing, and
add mutexes to protect against any race conditions that might otherwise
occur.

Since multi-threaded programming can be hard to get right, it is often
simpler to have the CA library operate in the single-threaded mode in
which only one callback can be active at once and the application's
thread must be inside a ca_pend_io(), ca_pend_event() or ca_poll() call
for callbacks to occur at all.

> Lastly, if there was a main thread like what you suggested, it seems
> to me that this could result in inefficient CA network I/O in certain
> cases.  For example, say there was a second thread (i.e. not the main
> thread) that was making ca_get_callback calls for *lots* of channels.
> According to the CA reference manual, the most efficient approach would
> be to make all those calls and then call one of ca_flush_io, ca_pend_io,
> ca_pend_event, or ca_sg_pend, to forward the accumulated get requests
> over the network to the CA server all at once (or at least in as few
> "messages" as possible).  If the main thread is calling ca_pend_event
> all the time, wouldn't that cause accumulating get requests in the
> second thread to be sent over the network prematurely?  Not that that's
> wrong, but it might be less efficient, right?

I understand your concern and you are correct about the effect, but my
example would only have flushed the queues out to the network every 0.1
seconds. This might have a minor effect, but I don't think it would be
noticeable on a modern CPU.

HTH,

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System