32 Thread support library [thread]

32.8 Coordination types [thread.coord]

32.8.1 General [thread.coord.general]

Subclause [thread.coord] describes various concepts related to thread coordination, and defines the coordination types latch and barrier.

These types facilitate concurrent computation performed by a number of threads.

32.8.2 Latches [thread.latch]

32.8.2.1 General [thread.latch.general]

A latch is a thread coordination mechanism that allows any number of threads to block until an expected number of threads arrive at the latch (via the count_down function).

The expected count is set when the latch is created.

An individual latch is a single-use object; once the expected count has been reached, the latch cannot be reused.

32.8.2.2 Header <latch> synopsis [latch.syn]

32.8.2.3 Class latch [thread.latch.class]

namespace std { class latch { public: static constexpr ptrdiff_t max() noexcept; constexpr explicit latch(ptrdiff_t expected); ~latch(); latch(const latch&) = delete; latch& operator=(const latch&) = delete; void count_down(ptrdiff_t update = 1); bool try_wait() const noexcept; void wait() const; void arrive_and_wait(ptrdiff_t update = 1); private: ptrdiff_t counter; // exposition only }; }

A latch maintains an internal counter that is initialized when the latch is created.

Threads can block on the latch object, waiting for counter to be decremented to zero.

Concurrent invocations of the member functions of latch, other than its destructor, do not introduce data races.

🔗

static constexpr ptrdiff_t max() noexcept;

Returns: The maximum value of counter that the implementation supports.

🔗

constexpr explicit latch(ptrdiff_t expected);

Preconditions: expected >= 0 is true and expected <= max() is true.

Effects: Initializes counter with expected.

Throws: Nothing.

🔗

void count_down(ptrdiff_t update = 1);

Preconditions: update >= 0 is true, and update <= counter is true.

Effects: Atomically decrements counter by update.

If counter is equal to zero, unblocks all threads blocked on *this.

Synchronization: Strongly happens before the returns from all calls that are unblocked.

Throws: system_error when an exception is required ([thread.req.exception]).

Error conditions: Any of the error conditions allowed for mutex types ([thread.mutex.requirements.mutex]).

🔗

bool try_wait() const noexcept;

Returns: With very low probability false.

Otherwise counter == 0.

🔗

void wait() const;

Effects: If counter equals zero, returns immediately.

Otherwise, blocks on *this until a call to count_down that decrements counter to zero.

Throws: system_error when an exception is required ([thread.req.exception]).

Error conditions: Any of the error conditions allowed for mutex types ([thread.mutex.requirements.mutex]).

🔗

void arrive_and_wait(ptrdiff_t update = 1);

Effects: Equivalent to: count_down(update); wait();

32.8.3 Barriers [thread.barrier]

32.8.3.1 General [thread.barrier.general]

A barrier is a thread coordination mechanism whose lifetime consists of a sequence of barrier phases, where each phase allows at most an expected number of threads to block until the expected number of threads arrive at the barrier.

[Note 1:

A barrier is useful for managing repeated tasks that are handled by multiple threads.

— end note]

32.8.3.2 Header <barrier> synopsis [barrier.syn]

32.8.3.3 Class template barrier [thread.barrier.class]

namespace std { template<class CompletionFunction = see below> class barrier { public: using arrival_token = see below; static constexpr ptrdiff_t max() noexcept; constexpr explicit barrier(ptrdiff_t expected, CompletionFunction f = CompletionFunction()); ~barrier(); barrier(const barrier&) = delete; barrier& operator=(const barrier&) = delete; [[nodiscard]] arrival_token arrive(ptrdiff_t update = 1); void wait(arrival_token&& arrival) const; void arrive_and_wait(); void arrive_and_drop(); private: CompletionFunction completion; // exposition only }; }

Each barrier phase consists of the following steps:

(1.1)
The expected count is decremented by each call to arrive or arrive_and_drop.
(1.2)
When the expected count reaches zero, the phase completion step is run.

For the specialization with the default value of the CompletionFunction template parameter, the completion step is run as part of the call to arrive or arrive_and_drop that caused the expected count to reach zero.

For other specializations, the completion step is run on one of the threads that arrived at the barrier during the phase.
(1.3)
When the completion step finishes, the expected count is reset to what was specified by the expected argument to the constructor, possibly adjusted by calls to arrive_and_drop, and the next phase starts.

Each phase defines a phase synchronization point.

Threads that arrive at the barrier during the phase can block on the phase synchronization point by calling wait, and will remain blocked until the phase completion step is run.

The phase completion step that is executed at the end of each phase has the following effects:

(3.1)
Invokes the completion function, equivalent to completion().
(3.2)
Unblocks all threads that are blocked on the phase synchronization point.

The end of the completion step strongly happens before the returns from all calls that were unblocked by the completion step.

For specializations that do not have the default value of the CompletionFunction template parameter, the behavior is undefined if any of the barrier object's member functions other than wait are called while the completion step is in progress.

Concurrent invocations of the member functions of barrier, other than its destructor, do not introduce data races.

The member functions arrive and arrive_and_drop execute atomically.

CompletionFunction shall meet the Cpp17MoveConstructible (Table 28) and Cpp17Destructible (Table 32) requirements.

is_nothrow_invocable_v<CompletionFunction&> shall be true.

The default value of the CompletionFunction template parameter is an unspecified type, such that, in addition to satisfying the requirements of CompletionFunction, it meets the Cpp17DefaultConstructible requirements (Table 27) and completion() has no effects.

barrier::arrival_token is an unspecified type, such that it meets the Cpp17MoveConstructible (Table 28), Cpp17MoveAssignable (Table 30), and Cpp17Destructible (Table 32) requirements.

🔗

static constexpr ptrdiff_t max() noexcept;

Returns: The maximum expected count that the implementation supports.

🔗

constexpr explicit barrier(ptrdiff_t expected,
                           CompletionFunction f = CompletionFunction());

Preconditions: expected >= 0 is true and expected <= max() is true.

Effects: Sets both the initial expected count for each barrier phase and the current expected count for the first phase to expected.

Initializes completion with std::move(f).

Starts the first phase.

[Note 1:

If expected is 0 this object can only be destroyed.

— end note]

Throws: Any exception thrown by CompletionFunction's move constructor.

🔗

[[nodiscard]] arrival_token arrive(ptrdiff_t update = 1);

Preconditions: update > 0 is true, and update is less than or equal to the expected count for the current barrier phase.

Effects: Constructs an object of type arrival_token that is associated with the phase synchronization point for the current phase.

Then, decrements the expected count by update.

Synchronization: The call to arrive strongly happens before the start of the phase completion step for the current phase.

Returns: The constructed arrival_token object.

Throws: system_error when an exception is required ([thread.req.exception]).

Error conditions: Any of the error conditions allowed for mutex types ([thread.mutex.requirements.mutex]).

[Note 2:

This call can cause the completion step for the current phase to start.

— end note]

🔗

void wait(arrival_token&& arrival) const;

Preconditions: arrival is associated with the phase synchronization point for the current phase or the immediately preceding phase of the same barrier object.

Effects: Blocks at the synchronization point associated with std::move(arrival) until the phase completion step of the synchronization point's phase is run.

[Note 3:

If arrival is associated with the synchronization point for a previous phase, the call returns immediately.

— end note]

Throws: system_error when an exception is required ([thread.req.exception]).

Error conditions: Any of the error conditions allowed for mutex types ([thread.mutex.requirements.mutex]).

🔗

void arrive_and_wait();

Effects: Equivalent to: wait(arrive()).

🔗

void arrive_and_drop();

Preconditions: The expected count for the current barrier phase is greater than zero.

Effects: Decrements the initial expected count for all subsequent phases by one.

Then decrements the expected count for the current phase by one.

Synchronization: The call to arrive_and_drop strongly happens before the start of the phase completion step for the current phase.

Throws: system_error when an exception is required ([thread.req.exception]).

Error conditions: Any of the error conditions allowed for mutex types ([thread.mutex.requirements.mutex]).

[Note 4:

This call can cause the completion step for the current phase to start.

— end note]