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: Does EPICS Base support multi-thread on vxWorks 6.3? |
From: | "Jeff Hill" <[email protected]> |
To: | <[email protected]> |
Cc: | [email protected] |
Date: | Tue, 19 Apr 2011 10:53:28 -0600 |
Ø The delay passed to ca_pend_event is 0.5s. Ø Ø I changed to call ca_context_create with ca_enable_preemptive_callback Ø (without any other change... and still calling ca_pend_event afterwards), Ø and found out the CPU 100% usage issue was gone. Weird! That is definitely weird, because changing to preemptive callback shouldn’t have that impact. I am suspicious that there is a bug, but I had a look at the ca client code and I don’t (yet) see an issue which would be impacted by preemptive callback mode being turned on/off. Please suspend the thread that is using CPU, and take some samples of its stack trace so we can see where the CPU is spending time. On vxWorks, with the target shell, one can suspend the thread with “ts <task id>”, print a stack trace with “tt <task id >”, and resume the thread with “tr <task id>”. If you repeat that sequence several times we should receive a good indication of where the CPU is being consumed. Considering this further, if there was an unexpected C++ exception occurring in ca_pend_event it would be caught by a try catch block at the membrane between C and C++. In that situation ca_pend_event would return ECA_INTERNAL and one could imagine that some CPU would be consumed, because the epicsThreadSleep in ca_pend_event might not be executed. Does ca_pend_event return ECA_INTERNAL? Are you using the old file descriptor registration features of the CA Client API? I suspect not. Knowing that you are not using that API eliminates some of the code in ca_pend_event from further scrutiny. Presumably this isn’t an SMP system (because it is ppc-603)? Note also that Alex Chen, also of NI, has some bug entries against EPICS at launch pad related to glitches in the advancement of time on windows, but they shouldn’t be relevant to vxWorks. 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]]
What delay is being passed to ca_pend_event? Otherwise, set a breakpoint in the function that uses CPU, to see who calls it, and how often. 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 [email protected]
|