RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

[Jay Steele <jsteele@xradia.com>]

Hi all,

     I tested the ca_get_callback function with Visual C++ 2008 and it worked quite nicely in my multi-threaded environment. I defined a static member function to be the callback function, and created a set of variables for multiple threads to store the data retrieved from EPICS and the flags indicating data received.

 

     I also tested the ca_put_callback function to set the VAL field for asyn motors, and only received the callback after the motor finished moving to its command position. Is this expected behavior? I was hoping for the callback to be received once the VAL field was set. Is there a way to configure the channel access software to make this happen?

 

Cheers,

Jay Steele

---

From: Jay Steele
Sent: Tuesday, August 16, 2011 2:10 PM
To: tech-talk@aps.anl.gov
Subject: RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

Hi Jeff,

     Thanks a lot for the quick response. I see that there are some nice tutorials on EPICS channel access on the Los Alamos web site.  

 

Cheers,

Jay Steele

Xradia Corporation

 

From: Jeff Hill [mailto:johill@lanl.gov]
Sent: Monday, August 15, 2011 5:23 PM
To: Jay Steele; tech-talk@aps.anl.gov
Subject: RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

 

Hi Jay,

 

Ø  However, when I launch another thread at priority THREAD_PRIORITY_ABOVE_NORMAL,

Ø  and this thread keeps the CPU busy, then for some reason the

Ø  ca_pend_io function returns with timeout

 

The ca client library spawns background threads at fixed offsets from the priority of the thread that created the ca context. Some of them run at lower priority and some at higher priority. If another higher priority uses all of the CPU then this definitely will cause the behavior that you are observing.

 

Generally it’s a suboptimal design to let one thread spin and use all of the CPU. That design prevents your code from coexisting with other programs and libraries. A better design is to have your consumer thread wait on a work queue. When adding to  the work queue post the work–is-pending semaphore, and the consumer thread of course waits on this same semaphore. You will of course also need a mutex lock to protect the work queue.

 

Would the ca_get_callback function work better for this situation?

 

The ca_pend_io mechanism works well for simple single threaded programs with short lifetimes. For multi-threaded applications, or for programs with longer life spans (that need to deal with connect/disconnect cycles) ca_get_callback works better.

 

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

With sufficient thrust, pigs fly just fine. However, this is

not necessarily a good idea. It is hard to be sure where they

are going to land, and it could be dangerous sitting under them

as they fly overhead. -- RFC 1925

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Jay Steele
Sent: Monday, August 15, 2011 4:23 PM
To: tech-talk@aps.anl.gov
Subject: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

 

Hi EPICS folks,

        I have some questions regarding an EPICS client and multi-threading on WINDOWS. Let me start by

laying out the development environment.

 

       I am developing an interface to an EPICS motor record using the CA API.

I am using base 3.14.8.2. I am compiling under Windows XP using Visual Studio

2008. I have successfully compiled all necessary components this way. I

know that there are no issues with the compiling because all of the

utilities and executables generated by the base are functional. My interface is

being generated in a GUI application for Windows XP. When I

start the program, the main process thread instantiates a class which

contains all of my EPICS related code. This class will connect to the

various PVs I require and store their chid objects for future access.

 

       For initialization, I call these functions from the main task.

 

int nRet = ca_context_create(ca_enable_preemptive_callback);

m_pEPICSContext = ca_current_context();

 

       I then go on to do other necessary steps for my program and eventually I

complete startup. Once startup has completed, there is a spawned thread

which will go to my EPICS class at a specified interval and retrieve new

data from the EPICS motors. This thread is priority THREAD_PRIORITY_ABOVE_NORMAL, is attached

to the main task’s context using ca_attach_context(m_pEPICSContext),

and periodically calls ca_get, then ca_pend_io to retrieve the motor data. I use

a 5 second timeout value for ca_pend_io. This normally works to successfully retrieve the motor data.

 

               However, when I launch another thread at priority THREAD_PRIORITY_ABOVE_NORMAL, and this thread keeps the CPU busy,

then for some reason the ca_pend_io function returns with timeout

(User specified timeout on IO operation expired). The WINDOWS O/S appears to swap CPU time between the two ABOVE_NORMAL priority threads,

But the ca_pend_io function still time outs. Is this expected behavior? Does the low level functionality in ca_pend_io run at a

low priority, so that it will timeout? Would the ca_get_callback function work better for this situation?

 

Thanks,

Jay Steele

Xradia Corporation

 

---

The information in this email, including any attachments, is confidential and intended only for the recipient(s) listed. Any use of this email for any other purpose is prohibited. If you have received this email in error, please notify me immediately by reply email, delete this email, and do not disclose its contents to anyone.

---

The information in this email, including any attachments, is confidential and intended only for the recipient(s) listed. Any use of this email for any other purpose is prohibited. If you have received this email in error, please notify me immediately by reply email, delete this email, and do not disclose its contents to anyone.