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.

### 3263. Atomic waiting function calls should only be unblocked once

Section: 31.6 [atomics.wait] Status: New Submitter: Geoffrey Romer Opened: 2019-08-19 Last modified: 2020-09-06

Priority: 3

View other active issues in [atomics.wait].

View all other issues in [atomics.wait].

View all issues with New status.

Discussion:

It appears that in a conforming implementation, all but one `wait()` call on a given atomic object may block forever, regardless of any `notify_one()` calls, because in principle every `notify_one()` call could be considered to unblock the same single `wait()` call. Common sense suggests (and David Olsen confirms) that the intent is for each waiting function call to be (non-spuriously) unblocked by at most one notifying function call, but as far as I can tell the words never say that.

[2019-09-14 Priority set to 3 based on reflector discussion]

Proposed resolution:

This wording is relative to N4830.

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

   > -?- All blocking and unblocking events on a single atomic object occur in a single total order that is consistent with the "happens before" partial order.

   > -4- A call to an atomic waiting operation on an atomic object `M` is eligible to be unblocked by a call to an atomic notifying operation on `M` if it has not been unblocked, and there exist side effects `X` and `Y` on `M` such that:

   > 1. (4.1) — the atomic waiting operation has blocked after observing the result of `X`,

   > 2. (4.2) — `X` precedes `Y` in the modification order of `M`, and

   > 3. (4.3) — `Y` happens before the call to the atomic notifying operation.