Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: asynDriver / epicsTimer bug
From: Eric Norum <norume@aps.anl.gov>
To: Dirk Zimoch <dirk.zimoch@psi.ch>
Cc: TECHTALK Tech-Talk <tech-talk@aps.anl.gov>, Mark Rivers <rivers@cars.uchicago.edu>
Date: Wed, 31 May 2006 08:54:40 -0500

On May 31, 2006, at 7:43 AM, Dirk Zimoch wrote:

Eric Norum wrote:

Hmm....
This sounds like a task starvation issue.  It appears that the read task is looping at a higher priority than the event timer callback task and so is preventing the callback from running.   My suspicion is that it's the vxWorks version of select() which is not rounding the timeout up to at least one tick.   If so, the problem will still be present in the latest version of ASYN. 

I called spy and found that the asyn port thread is indeed using up all CPU time at higher priority than e.g. CA or the timerQueues.

Good. The problem has been identified.
The latest version of ASYN will not have this "read forever" problem on vxWorks.  It will still have "issues", though. 

Consider the following situation:
1) vxWorks with a 100 Hz system clock.
2) An ASYN TCP/IP or UDP/IP read request with a timeout of 4 msec.

The read request will return any characters already present.  If no characters are present the request will *not* wait for up to 4 msec, but will return immediately.   This could cause the thread performing the read to loop and prevent lower-priority threads from getting any CPU time.  (I could argue that issuing such short-timeout calls in a loop is a sign of a bad application, but it would be best if ASYN helped protect programmers from themselves)

As a suggestion, how about we modify the ASYN IP port driver so that on vxWorks the local poll() routine rounds up non-zero timeouts to a miniumum of 1/epicsThreadSleepQuantum()?


-- 
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793



References:
asynDriver / epicsTimer bug Dirk Zimoch
Re: asynDriver / epicsTimer bug Dirk Zimoch
Re: asynDriver / epicsTimer bug Eric Norum
Re: asynDriver / epicsTimer bug Dirk Zimoch

Navigate by Date:
Prev: Re: asynDriver / epicsTimer bug Dirk Zimoch
Next: DirectLogic PLC ethernet driver? Sue Witherspoon
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: asynDriver / epicsTimer bug Dirk Zimoch
Next: Building a standalone IOC for an Intel embedded system Jon Brinkmann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·