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.
Section: 32.5.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.
Modify 32.5.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 objectM
is eligible to be unblocked by a call to an atomic notifying operation onM
if it has not been unblocked, and there exist side effectsX
andY
onM
such that:
(4.1) — the atomic waiting operation has blocked after observing the result of
X
,(4.2) —
X
precedesY
in the modification order ofM
, and(4.3) —
Y
happens before the call to the atomic notifying operation.