RE: cygwin and DOS caget, caput running slow at end due to ca_context_destroy(), option to speed up execution?

[Jay Steele <jsteele@xradia.com>]

Hi Mark and Jeff

    Are you guys running Windows XP? My results on my Windows XP computer are different than yours for some reason. I measure about 5 seconds to run caget and caput. Here’s more information.

 

1.       No significant delay using MEDM GUI CA client on the same Windows XP computer to get or modify PV values on VxWorks IOC.

2.       For caget and caput, 5 second delay occurs inside function epicsThreadPrivateGet called from ca_context_destroy to access PV records on VxWorks IOC.

 

     I could speculate that there is something wrong with my EPICS makefiles and I’m not using the correct option somewhere for the cygwin build, but I get the similar results (delay ~5 seconds) with the pre-compiled Win32 Extension caget function. Could there be some Windows XP environmental variable or setting for handling threads that I need to set?

 

   When I add some print statements to track where the cygwin caget code is stalling, the code stalls for the 5 seconds at the last pthread_getspecific call inside epicsThreadPrivateGet. For some reason, the initial call to pthread_getspecific within epicsThreadPrivateGet function launches  a succession of calls to epicsThreadPrivateGet. I cannot find where this recursive logic is. Here’s the output. I get the same output when I run caget to access a PV record field from the softIOC running on the same Windows computer, but without the ~5 second delay.

 

Epics/base/src/ca/access.cpp - ca_context_destroy(), calling epicsThreadPrivateGet with id = 5382720

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5382720, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

 

wait ~5 seconds . . .

 

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

Epics/base/src/ca/access.cpp - ca_context_destroy(), calling epicsThreadPrivateSet

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), id=5380552, calling assert

Epics/base/src/libCom/osi/os/posix/osdThread.c - epicsThreadPrivateGet(), calling pthread_getspecific

 

Cheers,

Jay Steele

 

 

From: Jeff Hill [mailto:johill@lanl.gov]
Sent: Wednesday, February 16, 2011 2:15 PM
To: Jay Steele; tech-talk@aps.anl.gov
Subject: RE: cygwin and DOS caget, caput running slow at end due to ca_context_destroy(), option to speed up execution?

 

Hi Jay,

 

I don’t see this either, but I am using only win32-x86 and win32-x86-mingw on my windows machines. The cygwin posix emulation adds some additional layers around windows sockets to obtain posix compatibility.

 

Ø  the majority of the execution time (4-5 seconds) seems to be spent running the ca_context_destroy function

 

The ca_context_destroy will wait for the tcp circuit shutdown handshake to finish before returning. You can watch this with netstat or in GUIs like, for example on windows, tcpview. The GUI might update the tcp state machine changes more rapidly as they are occurring.

 

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: Wednesday, February 16, 2011 1:00 PM
To: tech-talk@aps.anl.gov
Subject: cygwin and DOS caget, caput running slow at end due to ca_context_destroy(), option to speed up execution?

 

Hi EPICS folks,

      I’m running caget and caput utility functions from cygwin and DOS on a Windows XP system to get and put data to a VxWorks IOC on the same subnet. I would like to know if there is some option to help speed up the execution of these utility functions. For both sets of utility functions, the majority of the execution time (4-5 seconds) seems to be spent running the ca_context_destroy function at the end. I don’t see this delay when running caget and caput functions to get and put data to a Soft IOC running on the same Windows XP computer. I don’t understand why there is such a delay just to clean up at the end.

 

     I’m using epics base v3-14-11 for cygwin and EPICS WIN32 Extensions Version 1.40 (Build 40) for DOS.

 

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.