EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  <19951996  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: ca_pend_event question (VAX/VMS only)
From: [email protected] (Jeff Hill)
To: [email protected], [email protected]
Date: Tue, 8 Aug 95 18:27:27 MDT
> In the description of ca_pend_event in the Channel Access Reference Manual, 
> it says that a very short timeout such as 0.0001 seconds will result in a
> "poll".  It appears that on my VAX/VMS system, this "poll" really takes 
> around 10 milliseconds since the VAX time resolution is only to the
> nearest 10 msecs.  Has anybody ever looked into changing ca_pend_event
> so that it truly does a poll (at least on the VAX)?
> 

There are no explicit delays in ca_pend_event(). CA calls select() to see if
the file descriptors are active (specifying the delay provided by the 
application). Since select() can return early then I am required to call 
gettimeofday() to find out how much time has actually expired. 
In 3.12 I am waiting for at least some change in the clock and this is 
most likely where the VAX's 10mS resolution creeps in.

Others have complained about this and I have made some improvements. 
The R3.12 released code ca_pend_event() poll is taking about 888 uS 
on a sparc II. In my improved version of the code ca_pend_event() is 
taking about 310 uS. There is most likely still room for improvement. 

Under UNIX many applications get around the need to poll by waiting 
in select() ala "fdmgr.c". Unfortunately, this is not an option under VMS.
If I had more time I would look again at an AST driven version for VMS. 
The problem with this so far is trusting that there will be a standard 
interface to QIO maintained between VMS TCP/IP venders.

Another possibility is to use the thread library now available under VMS.
The CA client library could easily be modified to be thread safe in a VMS 
environment (it is already under vxWorks). Unfortunately, the MULTINET 
socket library isnt thread safe. If you isolated _all_ access to the ca 
client library in one thread only these problems could be carefully
avoided. You would most likely use a PV variable table and semaphores
to communicate with other threads. Give me a call if you would like to
discuss these matters in greater detail.

Jeff


______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107


Navigate by Date:
Prev: Re: BURT available on Alpha/Unix platform, but a few problems 415
Next: Choice of hardware Klaus Woerle
Index: 1994  <19951996  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 
Navigate by Thread:
Prev: ca_pend_event question (VAX/VMS only) SAA
Next: Re: ca_pend_event question (VAX/VMS only) Jeff Hill
Index: 1994  <19951996  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·