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
<2012>
2013
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|