Multi-threaded executions and data races (since C++11)

A thread of execution is a flow of control within a program that begins with the invocation of a specific top-level function (by std::thread, std::async , std::jthread (since C++20)

• When one thread creates another, the initial call to the top-level function of the new thread is executed by the new thread, not by the creating thread.

Any thread can potentially access any object and function in the program:

• Objects with automatic and thread-local storage duration may still be accessed by another thread through a pointer or by reference.
• Under a hosted implementation
• Under a freestanding implementation, it is implementation-defined whether a program can have more than one thread of execution.

For a signal handler that is not executed as a result of a call to std::raise

Data races

Different threads of execution are always allowed to access (read and modify) different memory locations

Two expression evaluations conflict

A program that has two conflicting evaluations has a data race unless

• both evaluations execute on the same thread or in the same signal handler, or
• both conflicting evaluations are atomic operations (see std::atomic), or
• one of the conflicting evaluations happens-before another (see std::memory_order).

If a data race occurs, the behavior of the program is undefined.

(In particular, release of a std::mutex is synchronized-with, and therefore, happens-before

int cnt = 0;
auto f = [&] { cnt++; };
std::thread t1{f}, t2{f}, t3{f}; // undefined behavior

std::atomic<int> cnt{0};
auto f = [&] { cnt++; };
std::thread t1{f}, t2{f}, t3{f}; // OK

Container data races

All containers in the standard library except std ::vector<bool>

std::vector<int> vec = {1, 2, 3, 4};
auto f = [&](int index) { vec[index] = 5; };
std::thread t1{f, 0}, t2{f, 1}; // OK
std::thread t3{f, 2}, t4{f, 2}; // undefined behavior

std::vector<bool> vec = {false, false};
auto f = [&](int index) { vec[index] = true; };
std::thread t1{f, 0}, t2{f, 1}; // undefined behavior

Memory order

When a thread reads a value from a memory location, it may see the initial value, the value written in the same thread, or the value written in another thread. See std::memory_order

Forward progress

Obstruction freedom

When only one thread that is not blocked in a standard library function executes an atomic function that is lock-free, that execution is guaranteed to complete (all standard library lock-free operations are obstruction-free

Lock freedom

When one or more lock-free atomic functions run concurrently, at least one of them is guaranteed to complete (all standard library lock-free operations are lock-free

Progress guarantee

In a valid C++ program, every thread eventually does one of the following:

• Terminates.
• Invokes std::this_thread::yield.
• Makes a call to an library I/O function.
• Performs an access through a volatile glvalue.
• Performs an atomic operation or a synchronization operation.
• Continues execution of a trivial infinite loop (see below).

A thread is said to make progress if it performs one of the execution steps above, blocks in a standard library function, or calls an atomic lock-free function that does not complete because of a non-blocked concurrent thread.

This allows the compilers to remove, merge and reorder all loops that have no observable behavior, without having to prove that they would eventually terminate because it can assume that no thread of execution can execute forever without performing any of these observable behaviors. An affordance is made for trivial infinite loops, which cannot be removed nor reordered.

Trivial infinite loops

A trivially empty iteration statement is an iteration statement matching one of the following forms:

The controlling expression of a trivially empty iteration statement is:

A trivial infinite loop is a trivially empty iteration statement for which the converted controlling expression is a constant expression, when manifestly constant-evaluated, and evaluates to true

The loop body of a trivial infinite loop is replaced with a call to the function std::this_thread::yield. It is implementation-defined whether this replacement occurs on freestanding implementations

for (;;); // trivial infinite loop, well defined as of P2809
for (;;) { int x; } // undefined behavior

Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

1. ↑ “Trivial” here means executing the infinite loop never makes any progress.