This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 786. Thread library timed waits, UTC and monotonic clocks

Section: 29 [time] Status: Resolved Submitter: Christopher Kohlhoff, Jeff Garland Opened: 2008-02-03 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [time].

View all issues with Resolved status.

Discussion:

The draft C++0x thread library requires that the time points of type `system_time` and returned by `get_system_time()` represent Coordinated Universal Time (UTC) (section [datetime.system]). This can lead to surprising behavior when a library user performs a duration-based wait, such as `condition_variable::timed_wait()`. A complete explanation of the problem may be found in the Rationale for the Monotonic Clock section in POSIX, but in summary:

- Operations such as `condition_variable::timed_wait()` (and its POSIX equivalent, `pthread_cond_timedwait()`) are specified using absolute times to address the problem of spurious wakeups.
- The typical use of the timed wait operations is to perform a relative wait. This may be achieved by first calculating an absolute time as the sum of the current time and the desired duration. In fact, the C++0x thread library includes duration-based overloads of `condition_variable::timed_wait()` that behave as if by calling the corresponding absolute time overload with a time point value of `get_system_time() + rel_time`.
- A UTC clock may be affected by changes to the system time, such as synchronization with an external source, leap seconds, or manual changes to the clock.
- Should the clock change during a timed wait operation, the actual duration of the wait will not be the expected length. For example, a user may intend a timed wait of one second duration but, due to an adjustment of the system clock backwards by a minute, the wait instead takes 61 seconds.

POSIX solves the problem by introducing a new monotonic clock, which is unaffected by changes to the system time. When a condition variable is initialized, the user may specify whether the monotonic clock is to be used. (It is worth noting that on POSIX systems it is not possible to use `condition_variable::native_handle()` to access this facility, since the desired clock type must be specified during construction of the condition variable object.)

In the context of the C++0x thread library, there are added dimensions to the problem due to the need to support platforms other than POSIX:

- Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
- Some environments do not have a monotonic clock, but do have a UTC clock.
- The Microsoft Windows API's synchronization functions use relative timeouts based on an implied monotonic clock. A program that switches from the Windows API to the C++0x thread library will now find itself susceptible to clock changes.

One possible minimal solution:

- Strike normative references to UTC and an epoch based on 1970-01-01.
- Make the semantics of `system_time` and `get_system_time()` implementation-defined (i.e standard library implementors may choose the appropriate underlying clock based on the capabilities of the target platform).
- Add a non-normative note encouraging use of a monotonic clock.
- Remove `system_time::seconds_since_epoch()`.
- Change the constructor `explicit system_time(time_t secs, nanoseconds ns = 0)` to `explicit system_time(nanoseconds ns)`.

Proposed resolution:

Rationale:

Addressed by N2661: A Foundation to Sleep On.