1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading |
From: | Jay Steele <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Tue, 16 Aug 2011 14:10:57 -0700 |
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:[email protected]]
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 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: [email protected] [mailto:[email protected]]
On Behalf Of Jay Steele 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. |