[Boost-bugs] [Boost C++ Libraries] #7719: C++11 steady_clock is not monotonic on Win32 & OSX

Subject: [Boost-bugs] [Boost C++ Libraries] #7719: C++11 steady_clock is not monotonic on Win32 & OSX
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-11-21 16:26:07

#7719: C++11 steady_clock is not monotonic on Win32 & OSX
 Reporter: fnjordy@… | Owner: viboes
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: chrono
  Version: Boost 1.52.0 | Severity: Problem
 Keywords: |
 Boost 1.52 defers to different OS specific calls for implementation of the
 std::chrono::steady_clock monotonic interface. There are supposed to be
 two characteristics: 1) monotonic, 2) independent of wall time. The
 current Boost implementation only achieves the latter.

 Issue raised from Stackoverflow: stackoverflow.com/q/13478093/175849

 Per platform discussion:

 '''POSIX''': defers to `clock_gettime (CLOCK_MONOTONIC)`. Generally
 sufficient excepting peculiarities of hyper-threading.

 '''OSX''': defers to `mach_absolute_time()` which is implemented by
 `RDTSC` which is only monotonic on the same core.

 Apple recommend per their documentation to use
 `clock_get_time(SYSTEM_CLOCK)` as a monotonic source. References:



 An important caveat is that the clock is not monotonic if
 `clock_set_time()` is called.

 '''Win32''': defers to `QueryPerformanceCounter()` which on many
 platforms is not monotonic due to dependency on `RDTSC` as a direct source
 or interpolation of times from more reliable sources such as HPET, RTC, or

 Microsoft in MSVC2012 implement `std::chrono` using `_Xtime_get_ticks()`
 which defers to `GetSystemTimeAsFileTime()` as discussed here (in


 This however is wall time and subject to clock changes, a more suitable
 source would be `GetTick64Count()` which requires Vista+, the alternative
 `GetTickCount()` wraps after 49.7 days.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/7719>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:11 UTC