Re: epicsTimer and rounding

[Eric Norum <eric@norum.ca>]

So what what's your recommendation for an RTEMS implementation of epicsThreadSleep?  

Constraints:

- Minimize floating point

- Don't make delays longer than necessary.  I'd expand your "0.0 doesn't sleep one quantum" to "epicsThreadSleep(N*epicsThreadSleepQuantum()) should call the underlying OS delay routine for a N-tick delay -- not N+1 ticks".

On Jun 8, 2012, at 8:04 AM, Ralph Lange wrote:

IMHO:
1. epicsTimer should not round.
2. epicsThreadSleep should always round up, following usual sleep/pause/nap/delay semantics, without forcing a sleep of one quantum when 0.0 is requested.
This matches the existing API specification. Currently, Windows, vxWorks, and RTEMS implementations do not follow the API spec, the posic implementation is correct.
2. The epicsTimer behaviour should be documented.
3. An application that wants statistically optimized delays may subtract half a quantum when setting up the epicsTimer. This should be mentioned in the documentation, and scan threads, ca beacons etc. should use this method. (Maybe add a "statistically more accurate" variant of the start method to the epicsTimer API for convenience.)

Cheers,
Ralph

-- 
Eric Norum
eric@norum.ca