Experimental Physics and
| |||||||||||||||||||||||||||
|
I'm not sharing a single CA client context between threads, I did make a call to ca_context_create() with ca_disable_preemptive_callback when a new thread is initiated. Is there any other reason that could cause similar issues? Andrew, thanks for your recommendation of using ca_enable_preemptive_callback, but that might not be my first choice. Lorna
Hi Lorna, On Friday 15 April 2011 02:34:53 [email protected] wrote: > > We developed a client based on libca (EPICS Base 3.14.9), which will > create it's own worker thread on construction. But we found it working > strangely on vxWorks (ppc-603). Whenever a second EPICS client is created > (meaning there are now 2 EPICS worker threads on vxWorks), the CPU usage > became 100%. > > From the profile, we found the ca_pend_event is consuming lots of the CPU. > > Meanwhile, it seems epicsMutex is failing to do the lock for the second > EPICS client?? EPICS should work fine on your hardware and OS combination, this is probably an application programming issue. Are these two threads sharing a single CA client context? Hopefully Jeff Hill will respond here too, but you might want to read this and the following sections of the CA Reference Manual for some ideas: http://www.aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#Thread In particular if you're experienced in writing multi-threaded code you might want to use ca_enable_preemptive_callback mode and completely avoid having to call ca_pend_event() in your code. - Andrew -- An error is only a mistake if you don't learn from it. When you learn something from it, it becomes a lesson.
| ||||||||||||||||||||||||||
ANJ, 18 Nov 2013 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |