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

### 3504. `condition_variable::wait_for` is overspecified

Section: 32.6.4 [thread.condition.condvar] Status: New Submitter: Jonathan Wakely Opened: 2020-11-18 Last modified: 2020-11-29

Priority: 3

View all other issues in [thread.condition.condvar].

View all issues with New status.

Discussion:

32.6.4 [thread.condition.condvar] p24 says:

> Effects: Equivalent to: `return wait_until(lock, chrono::steady_clock::now() + rel_time);`

This is overspecification, removing implementer freedom to make `cv.wait_for(duration<float>(1))` work accurately.

The type of `steady_clock::now() + duration<float>(n)` is `time_point<steady_clock, duration<float, steady_clock::period>>`. If the steady clock's period is `std::nano` and its epoch is the time the system booted, then in under a second a 32-bit `float` becomes unable to exactly represent those `time_points`! Every second after boot makes `duration<float, nano>` less precise.

This means that adding a `duration<float>` to a `time_point` (or `duration`) measured in nanoseconds is unlikely to produce an accurate value. Either it will round down to a value less than `now()`, or round up to one greater than `now() + 1s`. Either way, the `wait_for(rel_time)` doesn't wait for the specified time, and users think the implementation is faulty.

A possible solution is to use `steady_clock::now() + ceil<steady_clock::duration>(rel_time)` instead. This converts the relative time to a suitably large integer, and then the addition is not affected by floating-point rounding errors due to the limited precision of 32-bit `float`. Libstdc++ has been doing this for nearly three years. Alternatively, the standard could just say that the relative timeout is converted to an absolute timeout measured against the steady clock, and leave the details to the implementation. Some implementations might not be affected by the problem (e.g. if the steady clock measures milliseconds, or processes only run for a few seconds and use the process start as the steady clock's epoch).

This also affects the other overload of `condition_variable::wait_for`, and both overloads of `condition_variable_any::wait_for`.

[2020-11-29; Reflector prioritization]

Set priority to 3 during reflector discussions.

Proposed resolution: