Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Fri, 8 Jun 2012 09:44:30 -0400

Hi:

I think Ralph's example of how 'sleep' is used is correct.
Must sleep at least as long as requested.

What Jeff describes is a periodic timer.

The Java Timer class nicely offers both, allowing to
a) schedule a task after some delay, with at least that delay
b) schedule a periodic task, where the period between invocations might be
'squeezed' to achieve statistical correctness in the long run

These are different scenarios, and one epicsThreadSleep() can't do both.
The name epicsThreadSleep suggests to me that it's meant to be used for
the 'sleep', not for scheduling a periodic task.
That would require a different API like

epicsThreadPeriodic(...)

Thanks,
Kay

On 6/8/12 09:35 , "Ralph Lange" <[email protected]> wrote:
>Hi Jeff,
>
>On 06.06.2012 18:15, Hill, Jeff wrote:
>> I made that tweak (subtracting one half of the quantum from the timer
>>expiration time) when running the tests and attempting to optimize
>>measured timer expiration as close as possible to the specified
>>expiration time (on average).
>>
>> [...]
>
>OK, I understand the argumentation.
>
>Let me demonstrate the problem from the application side:
>
>I am interfacing to a serial device on RS-485.
>According to the device's spec, after sending a message, I have to make
>sure there is at least a 4ms break before sending the next message.
>I am configuring StreamDevice to wait for 5ms after the message.
>StreamDevice sets up an epicsTimer for 5ms. On Linux, the clock tick is
>usually 10ms, so epicsTimer substracts 5ms and calls epicsThreadSleep(0.0)
>The posix implementation of epicsThreadSleep calls nanosleep asking for
>a 0 delay, and gets a 0 delay.
>The next message is written on the RS-485 with zero delay (seen on a
>scope), the device barfs, communication goes haywire.
>
>I do see the beauty of statistical correctness, but this behavior is
>plain wrong.
>
>> Related to this issue is of course what goes on in epicsThreadSleep.
>>Note that, at least the windows version (see attached code at the end of
>>the email), does make certain of two things. Presumably similar code
>>exists for each of the OS specific implementations.
>>
>> 1) a sleep requested, less than one quantum, will be rounded up to one
>>quantum (the OS also probably makes this check)
>> 2) rounding occurs from the specified floating point seconds to the
>>nearest number of quantums by adding .5 to the floating point number of
>>quantums just before integer truncation.
>>
>> In your email you were worried that a sleep close to the quantum will
>>be off by 100% because of the one half quantum subtraction, but I
>>believe that all OS specific implementations force a sleep of less than
>>a quantum to be actually one quantum.
>
>Only for requested sleeps greater than zero.
>Requested epicsTimer sleeps of half a quantum or less will - after the
>half quantum subtraction - request from the OS a sleep of zero, which
>will not be rounded up by the OS specific implementation. No sleep at
>all. That is an error of 100%.
>
>> So Ralph makes the point that if the user ask for delay fff.fff then
>>there should never be a timer expiration occurring that is less than a
>>delay of fff.fff. So this is the crux of the matter isn't it; should we
>>make the timer expiration delay as close as possible to the user's
>>request on average (that's good for time algorithmic code such as a pid)
>>or should we guarantee timer expiration delay is never less than the
>>delay specified (maybe because we are concerned about cpu use with very
>>short timer delays but see the previous paragraph).
>
>It is application dependent. Short sleeps are usually intended as waits,
>so the application assumes it will wake up no earlier than after the
>requested time. This is why the OS specific sleep functions always round
>up, never down. And this is why I think the epicsTimer should behave the
>same way.
>
>In case an application wants a statistically optimized behavior, it can
>easily get the quantum and do the subtraction itself.
>
>I know this is symmetric (the application could add half a quantum when
>it wants the round-up behavior), but I would strongly suggest that the
>semantics of the epicsTimer follow the semantics of all reasonable OS's
>sleep implementations, and always round up to the next quantum.
>
>Cheers,
>~Ralph
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System