Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 5 May 2003 13:48:36 -0600

Hello Andrei,

I was cleaning out my mail today and I found your question. My
answer is inserted below.

Best regards,

Jeff

> 
> A small question about client Auxiliary Threads. The way in
> Auxiliary
> Thread is
> 1. Start thread.
> 2. Check current CA context
> 	struct ca_client_context * ca_current_context ();
> 3. if struct ca_client_context == NULL
> 		ca_context_create(ca_enable_preemptive_callback)
> //init CA
>    else
> 		int ca_attach_context (struct ca_client_context
> *CONTEXT);//join
> 4. WORK
> *****5. Does deattach_context need? (Of course, I can not call
> destroy.)

There is no need to provide a call which detaches from the CA
context because no resources were reserved by
ca_attach_context(). There is a call to destroy a CA context
after all of your threads are done with it.

> 6. Stop thread.
> 
> Best wishes,
> Andrei.
> 
> 
> 
> 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