Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 22 Apr 2003 18:37:36 -0600

Hello Andrei,

> 
> Can somebody show example with multithread client?

To set up a preemptive callback enabled CA client context you
will need code like this.

    SEVCHK(ca_context_create(ca_enable_preemptive_callback),
        "application pdq calling ca_context_create");

To set up a traditional single threaded client you will need code
like this.

    SEVCHK(ca_context_create(ca_disable_preemptive_callback),
        "application pdq calling ca_context_create");

I added these examples to the manual for the next release. 

> 
> But I could not image how I can say CA library to use new
> (auxiliary) thread for its callback fuctions. 

The CA client library spawns off its own private auxiliary
threads which call the user callbacks and take care of other
background activities.

> Is it possible I need to call
> ca_add_event() or ca_pend_event() in new thread?

The ca_add_event() function install a subscription for state
change call backs. It can be called from any thread in the CA
client context.

The ca_pend_event() function need not be called if you have
enabled preemptive callback. Otherwise, it should be called from
the thread that created the CA client context.

There is more information on ca client library contexts in the
latest CA client reference manual. Here is an excerpt.

Thread Safety and Preemptive Callback to User Code

Starting with EPICS R3.14 the CA client libraries are fully
thread safe on all OS (in past releases the library was thread
safe only on vxWorks). When the client library is initialized the
programmer may specify if preemptive call back is enabled.
Preemptive call back is disabled by default. If preemptive call
back is enabled then the user's call back functions might be
called by CA's auxiliary threads when the main initiating channel
access thread is not inside of a function in the channel access
client library. Otherwise, the user's call back functions will be
called only when the main initiating channel access thread is
executing inside of the CA client library. When the CA client
library invokes a user's call back function it will always wait
for the current callback to complete prior to executing another
call back function.
To set up a traditional single threaded client you will need code
like this (see ca_context_create and CA Client Contexts and
Application Specific Auxiliary Threads) .
SEVCHK ( ca_context_create(ca_disable_preemptive_callback ),
"application pdq calling ca_context_create" );
To set up a preemptive callback enabled CA client context you
will need code like this (see ca_context_createand CA Client
Contexts and Application Specific Auxiliary Threads) .
SEVCHK ( ca_context_create(ca_enable_preemptive_callback ),
"application pdq calling ca_context_create" );

CA Client Contexts and Application Specific Auxiliary Threads

It may be necessary for several CA client side tools running in
the same address space (process) to be independent of each other.
For example, the database CA links and the sequencer are designed
to not use the same CA client library threads, network circuits,
and data structures. Each thread that calls ca_context_create()
for the first time either directly, or implicitly when calling a
CA routine for the first time, creates a CA client library
context. A CA client library context contains all of the threads,
network circuits, and data structures required to connect and
communicate with the channels that a CA client application has
created. The priority of auxiliary threads spawned by the CA
client library are at fixed offsets from the priority of the
thread that called ca_context_create(). An application specific
auxiliary thread can join a CA context by calling
ca_attach_context() using the CA context identifier that was
returned from ca_current_context() when it was called by the
thread that called ca_context_create(). A CA client library
context can be shut down and cleaned up, after destroying any
channels or application specific threads that are attached to it,
by calling ca_context_destroy().

> 
> 	I see epicsThread.h and epicsThread.cpp files. I believe
> this is wrapper over os-depending threading. Am I right? 

Yes. See the application developer's guide.

> Can I use this wrapper to hide Windows and Linux threads? 
> Can I see example too? Or have epicsThreadTestMain.cpp 
> and epicsThreadPrivateTest.cpp examples
> enough information?

That?s a reasonable starting point. There are also many other
codes in base 8-]

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System