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: Ralph Lange <Ralph.Lange@gmx.de>
To: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Thu, 14 Jun 2012 12:44:45 +0200
On 14.06.2012 04:19, Eric Norum wrote:
> I think that epicsThreadSleep(x) should guarantee to return only after at least x seconds have elapsed.  
> This is in line with the semantics of every other implementation of similar functions of which I'm aware.

And it does!

There are two separate issues.

1) Jeff's C++ epicsTimer compensates by subtracting half a quantum.
IMHO, this API should be changed to that the client can select between
"round-up" and "round" behavior, making "round-up" the default. As an
API change, that should go to 3.15

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.

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.

Note that 2) does not make epicsThreadSleep(x) return early!

~Ralph


> On Jun 13, 2012, at 6:12 PM, Hill, Jeff wrote:
>
>> Hi Andrew, Ralph,
>>
>> We will need to decide how to proceed with the timer delay 
>> compensation issue. I am extremely busy so it will be easy 
>> for this to fall through the cracks. 
>>
>> It occurs to me that this issue could also be fixed by just not
>> compensating the timer delay when the requested delay is less than one 
>> quantum, but otherwise leaving the compensation code in place. I think 
>> I mentioned that option before, but I suspect that Ralph is in favor only 
>> of a solution that 100% removes the compensation. I mention this 
>> option again only because it would be easier to justify as a backwards
>> compatible bug fix, and therefore as an R3.14 patch. I believe that
>> Andrew is not in favor of a change that removes the compensation 100% 
>> from R3.14, and would postpone that change to R3.15.
>>
>> What do you think? I am happy to implement whatever the community 
>> consensus is.
>>
>> Jeff
>>



Replies:
Re: timer delay compensation Benjamin Franksen
Re: timer delay compensation Eric Norum
Re: timer delay compensation Andrew Johnson
Re: timer delay compensation Andrew Johnson
References:
timer delay compensation Hill, Jeff
Re: timer delay compensation Eric Norum

Navigate by Date:
Prev: Re: timer delay compensation Eric Norum
Next: Re: timer delay compensation Benjamin Franksen
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 Benjamin Franksen
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 ·