EPICS Controls 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  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: timer delay compensation
From: Eric Norum <[email protected]>
To: Ralph Lange <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 14 Jun 2012 08:12:56 -0700
On Jun 14, 2012, at 3:44 AM, Ralph Lange wrote:

> 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!

???
The code now does not match the above the description.
The implementations for both vxWorks and RTEMS exhibit the following behaviour:
	For quantum=10ms a request to sleep for 14ms will possibly return in as little as 10+epsilon ms.
	This violates the semantics mentioned above -- so I would argue that, "it does not".
That's the whole reason that we're having this discussion, right?

> 
> 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

Perhaps.
The implementations have been wrong for so long that there may be code out there depending on the improper behaviour.

> 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.

How does, "epicsThreadSleep(x) is guaranteed to return only after at least x seconds have elapsed" disagree from the text now in the application developer's guide?
I see nothing in the guide that describes the existing (broken) rounding  behaviour.

> 
> 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 think that a request for a sleep of 0 should *not* result in an up-to-1 quantum delay.  Rather it should behave merely as a 'yield' action allowing another thread at the same priority to run.  If there are no other threads at the same priority it should have no effect.
A request of (0.00000000000001) seconds *should* result in an up-to-1 quantum delay.
These two sentences are completely in agreement with my original comment above, "epicsThreadSleep(x) is guaranteed to return only after at least x seconds have elapsed".


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

Right.
It should *never* return early.
The existing implementations are wrong in my opinion.  And I say that even through I suspect that I am responsible for the RTEMS implementation.   I clearly was not thinking well when I wrote that code.
-- 
Eric Norum
[email protected]



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 Benjamin Franksen
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  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: timer delay compensation Benjamin Franksen
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  2021  2022  2023  2024 
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 ·