Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: timer delay compensation
From: Andrew Johnson <anj@aps.anl.gov>
To: core-talk@aps.anl.gov
Date: Thu, 14 Jun 2012 11:09:46 -0500
Hi Ralph,

On 2012-06-14 Ralph Lange wrote:
> Jeff is right that I do not like the idea of changing the rounding
> behavior over the range of possible delays. That would obscure the spec,
> confuse the user, and introduce OS-implementation dependent behavior in
> the OS-independent part of libCom. I'd rather let 3.14 live with the
> current state, and document it.

Agreed.

> 2) Some (=many) epicsThreadSleep(x) implementations do not work as
> defined and advertised, by calling the OS for a 1-quantum sleep even for
> a requested sleep of zero. Making the behavior consistent and to spec is
> a fix that goes into 3.14 and up.

I agree with Eric here; the epicsThreadSleep() implementations that round up 
to the nearest tick all have code that explicitly compares seconds with zero 
and do *not* round up in that case; they all call the underlying OS delay 
routine with a tick count of zero.  This provides a way for code to yield the 
CPU to other threads that are running at the same thread priority.  The 
vxWorks documentation describes this:

> As a side effect, taskDelay( ) moves the calling task to the end of the
> ready queue for tasks of the same priority. In particular, you can yield
> the CPU to any other tasks of the same priority by "delaying" for zero
> clock ticks:
>
>    taskDelay (NO_WAIT);     /* allow other tasks of same priority to run */

vxWorks.h defines NO_WAIT as 0.

We should not change the zero-delay behavior of any implementation, unless it 
doesn't currently actually implement that yield correctly.

However our handling of non-zero delays is a different matter; in all cases 
there we seem to be rounding to the nearest tick and adding 1 if the result is 
zero ticks, which as Eric points out is probably wrong.

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

References:
timer delay compensation Hill, Jeff
Re: timer delay compensation Eric Norum
Re: timer delay compensation Ralph Lange

Navigate by Date:
Prev: Re: timer delay compensation Eric Norum
Next: Re: timer delay compensation Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: timer delay compensation Eric Norum
Next: Re: timer delay compensation Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·