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.

4625. Blocking the thread of execution should be a non-constant library call

Section: 32.5.6 [atomics.wait] Status: New Submitter: Jan Schultke Opened: 2026-09-21 Last modified: 2026-09-26

Priority: Not Prioritized

View other active issues in [atomics.wait].

View all other issues in [atomics.wait].

View all issues with New status.

Discussion:

32.5.8.2 [atomics.types.operations] specifies that std::atomic<T>::wait is constexpr and that it blocks the thread if the given value is equal to the current value of the object. Other atomic waiting operations (32.5.6 [atomics.wait]) can also block, such as std::atomic_flag::wait.

P3309R3 argues that blocking the thread is not a constant expression because it exceeds implementation limits, but it is unclear which (if any) implementation limits are exceeded by blocking. One might also argue that blocking the thread violates the forward progress guarantee (6.10.2.3 [intro.progress]), which is undefined behavior and thus not a core constant expression, but this explanation is contrived.

See prior discussion at

Proposed resolution:

This wording is relative to N5054.

  1. Modify 32.5.6 [atomics.wait] as indicated:

    -1- Atomic waiting operations and atomic notifying operations provide a mechanism to wait for the value of an atomic object to change more efficiently than can be achieved with polling. An atomic waiting operation may block until it is unblocked by an atomic notifying operation, according to each function's effects. An atomic waiting operation that blocks is a non-constant library call (3.35 [defns.nonconst.libcall]).

    [Note 1: Programs are not guaranteed to observe transient atomic values, an issue known as the A-B-A problem, resulting in continued blocking if a condition is only temporarily met. — end note]