[thread.req.timing]

# 32 Concurrency support library [[thread]](./#thread)

## 32.2 Requirements [[thread.req]](thread.req#timing)

### 32.2.4 Timing specifications [thread.req.timing]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L90)

Several functions described in this Clause take an argument to specify a timeout[.](#1.sentence-1)

These
timeouts are specified as either a duration or a time_point type as
specified in [[time]](time "30 Time library")[.](#1.sentence-2)

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L95)

Implementations necessarily have some delay in returning from a timeout[.](#2.sentence-1)

Any overhead in
interrupt response, function return, and scheduling induces a “quality of implementation”
delay, expressed as duration Di[.](#2.sentence-2)

Ideally, this delay would be zero[.](#2.sentence-3)

Further, any contention for
processor and memory resources induces a “quality of management” delay, expressed as durationDm[.](#2.sentence-4)

The delay durations may vary from timeout to timeout, but in all cases shorter is better[.](#2.sentence-5)

[3](#3)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L102)

The functions whose names end in _for take an argument that
specifies a duration[.](#3.sentence-1)

These functions produce relative timeouts[.](#3.sentence-2)

Implementations
should use a steady clock to measure time for these functions[.](#3.sentence-3)[293](#footnote-293 "Implementations for which standard time units are meaningful will typically have a steady clock within their hardware implementation.")

Given a duration
argument Dt, the real-time duration of the timeout is Dt+Di+Dm[.](#3.sentence-4)

[4](#4)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L113)

The functions whose names end in _until take an argument that specifies a time
point[.](#4.sentence-1)

These functions produce absolute timeouts[.](#4.sentence-2)

Implementations should use the clock
specified in the time point to measure time for these functions[.](#4.sentence-3)

Given a clock time point
argument Ct, the clock time point of the return from timeout should be Ct+Di+Dm when the clock is not adjusted during the timeout[.](#4.sentence-4)

If the clock is adjusted to the time Ca during the timeout, the behavior should be as follows:

- [(4.1)](#4.1)

  If Ca>Ct, the waiting function should wake as soon as possible, i.e., Ca+Di+Dm,
since the timeout is already satisfied[.](#4.1.sentence-1)
  This specification may result in the total
duration of the wait decreasing when measured against a steady clock[.](#4.1.sentence-2)

- [(4.2)](#4.2)

  If Ca≤Ct, the waiting function should not time out until Clock​::​now() returns a
time Cn≥Ct, i.e., waking at Ct+Di+Dm[.](#4.2.sentence-1)
  [*Note [1](#note-1)*:
  When the clock is adjusted
backwards, this specification can result in the total duration of the wait increasing when
measured against a steady clock[.](#4.2.sentence-2)
  When the clock is adjusted forwards, this specification can
result in the total duration of the wait decreasing when measured against a steady clock[.](#4.2.sentence-3)
 — *end note*]

An implementation returns from such a timeout at any point from the time specified above to
the time it would return from a steady-clock relative timeout on the difference between Ct and the time point of the call to the _until function[.](#4.sentence-6)

*Recommended practice*: Implementations
should decrease the duration of the wait when the clock is adjusted forwards[.](#4.sentence-7)

[5](#5)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L146)

[*Note [2](#note-2)*:

If the clock is not synchronized with a steady clock, e.g., a CPU time clock, these
timeouts can fail to provide useful functionality[.](#5.sentence-1)

— *end note*]

[6](#6)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L152)

The resolution of timing provided by an implementation depends on both operating system
and hardware[.](#6.sentence-1)

The finest resolution provided by an implementation is called the[*native resolution*](#def:native_resolution)[.](#6.sentence-2)

[7](#7)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L157)

Implementation-provided clocks that are used for these functions meet the[*Cpp17TrivialClock*](time.clock.req#:Cpp17TrivialClock "30.3 Cpp17Clock requirements [time.clock.req]") requirements ([[time.clock.req]](time.clock.req "30.3 Cpp17Clock requirements"))[.](#7.sentence-1)

[8](#8)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/threads.tex#L161)

A function that takes an argument which specifies a timeout will throw if,
during its execution, a clock, time point, or time duration throws an exception[.](#8.sentence-1)

Such exceptions are referred to as [*timeout-related exceptions*](#def:timeout-related_exceptions)[.](#8.sentence-2)

[*Note [3](#note-3)*:

Instantiations of clock, time point and duration types supplied by
the implementation as specified in [[time.clock]](time.clock "30.7 Clocks") do not throw exceptions[.](#8.sentence-3)

— *end note*]

[293)](#footnote-293)[293)](#footnoteref-293)

Implementations for which standard time units are meaningful will typically
have a steady clock within their hardware implementation[.](#footnote-293.sentence-1)