Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 16 Dec 2015 16:26:58 -0600

Hi Lewis,

On 12/16/2015 10:10 AM, J. Lewis Muir wrote:
> On 12/15/15 6:39 PM, Andrew Johnson wrote:
>> On 12/15/2015 05:19 PM, Michael Davidsaver wrote:
>>> I would point out that allowing jumps backwards will allow timers to
>>> expire early as the timer queue uses general time.
>>
>> The epicsEventWaitWithTimeout() and epicsThreadSleep() APIs are both
>> safe since they're implemented using tick counts on the two RTOS's,
>> but you're talking about Jeff's epicsTimer implementations, which I
>> now see do absolute time comparisons to determine when a timer should
>> go off.
> 
> Hi, Andrew!
> 
> So those two APIs are safe on the two RTOSes (vxWorks and RTEMS, I
> assume), but not on others, right?  Obviously, there are *lots* of soft
> IOCs out there, so this issue would apply to all of those.

None of the other OSs use generalTime to set their time-of-day clock,
they all have some other OS-specific way of synchronizing with NTP, so
the particular issue that I was discussing here doesn't apply to them in
quite the same way. If the OS allows the time to jump, that may have
similar effects on any OS APIs that handle time and delays, such as
select(), nanosleep() etc.

>> I'm not sure how big a problem this is in practice.
> 
> To me, a timer or similar API that expires early is a bug (unless
> documented to allow for early expiration, but that might make the API
> difficult to use or worthless) and can lead to all kinds of problematic
> behavior.  I would love for all timers to work correctly on all
> platforms.  I'm not closely following the core development, but perhaps
> you could implement a monotonic time source and use it for soft IOC
> timer implementations.

As I see it there are two different kinds of timers that users might
want to use. In some cases they want a timer that will fire "at least N
seconds from now", while in others they want one that will fire "as soon
as possible after absolute time T". The epicsTimer classes actually
provide both methods:
    void start (epicsTimerNotify &, double delaySeconds);
    void start (epicsTimerNotify &, const epicsTime &);

However they only implement what they promise when the wall-clock time
advances smoothly. The first method is actually implemented by calling
epicsTimeGetCurrent(), adding the delay and then calling the second
method, thus if the wall-clock time returned by epicsTimeGetCurrent()
ever jumps forward while an epicsTimer using the delay method is
ticking, it may fire before the requested delay is up. If the timer was
given an absolute trigger time though, I would want it to trigger as
soon as the requested wall-clock time arrived.

If we had a true monotonic clock as you and Michael propose we could use
that to implement the delay timer to avoid early triggers, but we would
have to be careful not to break timers triggered with an absolute time —
they should continue to use something like the current implementation.

- Andrew
-- 
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
    -- Terry Pratchett, Reaper Man

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System