Boost C++ Libraries: Ticket #3504: deadline_timer (based on UTC time) is not suitable for communication timeouts

attachment set

Fri, 02 Oct 2009 07:39:22 GMT

attachment → monotone_timer.hpp

monotone_timer.hpp

version changed; cc set

Mon, 23 Nov 2009 12:50:27 GMT

cc pgquiles@… added
version Boost 1.38.0 → Boost 1.41.0

I can confirm Asio timers are broken if you set the date back/forward. The timer does not need to fire any fast, you can fire the timer just once a day and it will fail if you do this:

Let's say the time now is 2009-11-23 13:45:20
Start timer with deadline in 1 hour. Asio watches the system and will fire the timer at 2009-11-23 14:45:20.
Set date back 1 day: 2009-11-22 13:45:20
Timer never fires

While Bjarne's solution is good, the #ifdef for Linux is not. It should not check for Linux but for platforms where clock_gettime is available, which is done with "#if defined(_POSIX_TIMERS) && ( _POSIX_TIMERS > 0 ) && defined(_POSIX_MONOTONIC_CLOCK)".

I've fixed Bjarne's code and uploaded the attachment.

In addition to that, on Linux with glibc >= 2.11, linking with librt is required. Linux with glibc <= 2.9 does not need linking with librt but it does not do any harm, either. FreeBSD and Mac OS X do not need linking with librt.

attachment set

Mon, 23 Nov 2009 12:52:18 GMT

attachment → monotone_timer.hpp-PROPER_IFDEF

Fix #ifdef for Unix platforms

attachment set

victor — Wed, 30 Dec 2009 08:41:13 GMT

attachment → monotone_timer.2.hpp

discard mutex on windows

victor — Wed, 30 Dec 2009 08:45:02 GMT

There is static mutex in function 'now' on windows. If there r lots of connection which own monotone_timer, ther will be execute one by one because this static mutex. I fixed the code and unploaded the attachment

status changed; resolution set

chris_kohlhoff — Tue, 12 Jan 2010 22:17:44 GMT

status new → closed
resolution → wontfix

I agree with the need for a monotonic timer. However, I consider the provision of a monotonic clock to be out of scope for asio. The date_time library might be better. Alternatively, once c++0x library implementations are available we may use those. Once a monotonic clock is available I will look at adding a monotonic_timer to asio.

status changed; resolution deleted

anonymous — Wed, 13 Jan 2010 08:43:46 GMT

status closed → reopened
resolution wontfix

Let me disagree. Timers are implemented in asio, not in date_time. Even if only for coherence (other timers are implemented in asio not in date_time), it makes no sense at all to implement the monotonic timer in date_time instead of asio. Please, reconsider your position.

status changed; resolution set

chris_kohlhoff — Wed, 13 Jan 2010 11:48:53 GMT

status reopened → closed
resolution → wontfix

Let me restate:

Yes, a monotonic_timer would be a good addition to asio. Asio is the right place for this.

A monotonic clock is a prerequisite for a monotonic_timer.

The provision of a monotonic clock is out of scope for asio as far as I'm concerned. By clock, I mean the monotonic equivalent of boost::posix_time::microsec_clock::universal_time().

I hope that makes it clear.

anonymous — Thu, 28 Jan 2010 21:54:33 GMT

Replying to victor:

There is static mutex in function 'now' on windows. If there r lots of connection which own monotone_timer, ther will be execute one by one because this static mutex. I fixed the code and unploaded the attachment

this version uses _ftime instead of GetTickCount for windows. The original problem seems to return using any system time function other than GetTickCount ???

attachment set

anonymous — Mon, 15 Mar 2010 02:52:03 GMT

attachment → monotone_timer.hpp-NO_MUTEX

Removed need for mutex while maintaining monotonic functionality

anonymous — Mon, 15 Mar 2010 06:10:52 GMT

I've looked into the QueryPerformanceXXXXX functions and it seems they may not be as accurate as I would like. While the GetTickCount version requires a mutex it may be better to suffer a possible small performance hit in order to maintain accuracy.

If anyone has any up to date knowledge of any issues with the QueryPerformanceXXXXX functions I would appreciate it.

simon.reye@… — Mon, 15 Mar 2010 22:28:11 GMT

Replying to anonymous:

I've looked into the QueryPerformanceXXXXX functions and it seems they may not be as accurate as I would like. While the GetTickCount version requires a mutex it may be better to suffer a possible small performance hit in order to maintain accuracy.

If anyone has any up to date knowledge of any issues with the QueryPerformanceXXXXX functions I would appreciate it.

In the past they have been a problem, especially on multi-core processors but MSDN assures us that QueryPerformanceFrequency will not change once the system has started.

http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx

anonymous — Wed, 18 Aug 2010 01:36:05 GMT

I'm confused as to why this is "wontfix". As it stands, any change in the system time completely screws up any system relying on the deadline timer. If not for the files and ideas presented here I would have been lost.

You cannot use the system time for timers.

kjohnson@… — Thu, 25 Nov 2010 21:16:39 GMT

I may be wrong, but I think the attached file "monotone_timer.hpp-NO_MUTEX" suffers from really bad roll over issues. Multiplying a rolling monotonic timer by a constant (1000000000/frequency.QuadPart on line 80) doesn't produce a valid monotonic nanosecond count.

I've attached the version I'm trying which keeps times and durations in terms of the performance counter (monotone_timer_better_rollover.cpp/.hpp).

You use it as: TimerImpl m_Timer; m_Timer.expires_from_now(TimerTraits::milliseconds_to_duration(milliseconds_delay));

I agree that this is a really big issue. I was hoping when we started using boost that we would be spending out time writing our application, not spending hours trying to get a basic timer working reliably.

I also think the documentation should be changed. The example provided (e.g. http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/example/timers/tick_count_timer.cpp) is *WRONG* and doesn't work as expected.

attachment set

anonymous — Thu, 25 Nov 2010 21:17:15 GMT

attachment → monotone_timer_better_rollover.cpp

attachment set

anonymous — Thu, 25 Nov 2010 21:17:27 GMT

attachment → monotone_timer_better_rollover.hpp

Fri, 27 May 2011 16:56:48 GMT

I'd like to resubmit this feature request now that boost::chrono::steady_clock is available on the release branch.

anonymous — Fri, 01 Jul 2011 12:15:35 GMT

Replying to kjohnson@…:

I may be wrong, but I think the attached file "monotone_timer.hpp-NO_MUTEX" suffers from really bad roll over issues. Multiplying a rolling monotonic timer by a constant (1000000000/frequency.QuadPart on line 80) doesn't produce a valid monotonic nanosecond count.

I've attached the version I'm trying which keeps times and durations in terms of the performance counter (monotone_timer_better_rollover.cpp/.hpp).

You use it as: TimerImpl m_Timer; m_Timer.expires_from_now(TimerTraits::milliseconds_to_duration(milliseconds_delay));

Your attached code uses a header named CheckedInt64.h, could you add this as well please?

cc changed

Wed, 13 Jul 2011 11:38:57 GMT

cc leon@… added

kjohnson@… — Thu, 14 Jul 2011 01:36:42 GMT

It is just a class that performs 64-bit arithmetic with overflow checking. This is internal code that I would require permission to release - honestly I can't be bothered doing this. You can just replace it with normal 64-bit arithmetic if you want.

e.g.

boost::posix_time::time_duration TimerTraits::to_posix_duration(

const TimerTraits::duration_type& d)

{

return boost::posix_time::milliseconds(d.ticks_ * 1000 / performance_freq_);

}

Replying to anonymous:

Replying to kjohnson@…:

I may be wrong, but I think the attached file "monotone_timer.hpp-NO_MUTEX" suffers from really bad roll over issues. Multiplying a rolling monotonic timer by a constant (1000000000/frequency.QuadPart on line 80) doesn't produce a valid monotonic nanosecond count.

I've attached the version I'm trying which keeps times and durations in terms of the performance counter (monotone_timer_better_rollover.cpp/.hpp).

You use it as: TimerImpl m_Timer; m_Timer.expires_from_now(TimerTraits::milliseconds_to_duration(milliseconds_delay));

Your attached code uses a header named CheckedInt64.h, could you add this as well please?

Aaron_Wright@… — Wed, 02 Nov 2011 22:12:11 GMT

Replying to kjohnson@…:

I may be wrong, but I think the attached file "monotone_timer.hpp-NO_MUTEX" suffers from really bad roll over issues. Multiplying a rolling monotonic timer by a constant (1000000000/frequency.QuadPart on line 80) doesn't produce a valid monotonic nanosecond count.

I'm investigating an issue I've had where timers have stopped firing. I used an implementation just like "monotone_timer.hpp-NO_MUTEX", and I was wanting to narrow down the cause of my problem.

Would it be possible to get a little more detail about why that equation doesn't "produce a valid monotonic nanosecond count"? I would really appreciate it.

kjohnson@… — Tue, 08 Nov 2011 03:50:31 GMT

Replying to Aaron_Wright@…:

Replying to kjohnson@…:

I may be wrong, but I think the attached file "monotone_timer.hpp-NO_MUTEX" suffers from really bad roll over issues. Multiplying a rolling monotonic timer by a constant (1000000000/frequency.QuadPart on line 80) doesn't produce a valid monotonic nanosecond count.

I'm investigating an issue I've had where timers have stopped firing. I used an implementation just like "monotone_timer.hpp-NO_MUTEX", and I was wanting to narrow down the cause of my problem.

Would it be possible to get a little more detail about why that equation doesn't "produce a valid monotonic nanosecond count"? I would really appreciate it.

I was wrong - it doesn't.

It is always true that:

((count+n)*ns_over_freq) - (count*ns_over_freq) = (n*ns_over_freq)

in the ring of unsigned 64-bit numbers - i.e. monotonic steps in the count always produce monotonic steps in the output - it just wraps around more often.

I was obviously a bit confused and frustrated that day.

I did warn you :)

There were a couple of fixes in 1.45 that you may be interested in.

https://svn.boost.org/trac/boost/ticket/4568

https://svn.boost.org/trac/boost/ticket/4745

I've moved off this now and probably can't help anymore.

attachment set

bwhite@… — Tue, 24 Jan 2012 18:05:37 GMT

attachment → MonotonicDeadlineTimer.h

monotonic_deadline_timer using boost::chrono::steady_clock

bwhite@… — Tue, 24 Jan 2012 18:13:53 GMT

I've attached a header file that I recently implemented in our product that was suffering the same issue described in this thread. It provides a ready-to-use boost::asio::monotonic_deadline_timer class that is powered by the boost::chrono::steady_clock. So far in our testing adjusting the system clock forward or back no longer impacts when the timer fires. When you ask for, say, 10 seconds you always get 10 seconds. Hopefully this or something similar will appear in a future Boost version. Enjoy!

Fri, 04 May 2012 15:48:23 GMT

Any new plans to fix this or have a monotonic_dealine_timer officially included in Boost?

Also, I noticed a similar behavior using this_thread::sleep()

status, severity, type, component, version, milestone changed; resolution deleted

Smithe687 — Sat, 24 Dec 2016 06:11:34 GMT

status closed → reopened
severity Problem → Not Applicable
type Feature Requests → Library Submissions
component asio → xpressive
version Boost 1.41.0 → Boost.Build-M3
milestone Boost 1.41.0 → Website 1.X
resolution wontfix

Hello! Do you use Twitter? I'd like to follow you if that would be okay. I'm undoubtedly enjoying your blog and look forward to new posts. dfcdefcffabedadc

type, version, component, severity, milestone changed

Tue, 27 Dec 2016 13:39:31 GMT

type Library Submissions → Feature Requests
version Boost.Build-M3 → Boost 1.41.0
component xpressive → asio
severity Not Applicable → Problem
milestone Website 1.X → To Be Determined

Undid vandalism. I would like to take this opportunity to reiterate my request that deadline_timer be based on boost::chrono::steady_clock.