Interjection here, but isn't the point of atomic wait/notify to implement things like condition variables? In that case, a read-only operation in relaxed ordering would not be required to obtain any value written before notify_one unless notify_one has an implied release. I'm unsure that the implied "happens before" ordering for notify exists especially given spurious wakeups could cause it to return before write and a write could happen in relaxed mode which implies no ordering. I doubt this is an issue in practice since the kernel will probably flush caches on context switch triggering a seq_cst-like behavior, but it's good to think about. I would say notify does NOT order anything and you "must" use acquire/release on the atomic to get ordering. Anything else could require a lot of overhead in the implementation if the kernel doesn't flush caches. My assumption is that wait/notify are intended as low level wrappers that map directly to SYS_futex, waitv, WaitForMultipleObjectsEx and similar system calls, so any kind of sequencing would make the implementation tricky if missing in any OS.

--
Ryan Nicholl
(678)-358-7765
Sent from Proton Mail mobile
-------- Original Message --------
On Jul 19, 2022, 07:39, language.lawyer--- via Std-Discussion wrote:
> On 19/07/2022 16:28, Marcin Jaczewski wrote: > But for `notify` explicitly say it NEED to do in that way that `wait` > WILL see it correctly. > The Definition of `wait` on its own is not enough, you need to read > the whole standard and all cross references, > like in the case of `memcpy` that all special guarantees are placed in > multiple places of standard. I've re-checked the definition of notify, of wait and of "eligible to be unblocked" and still do not see how the visibility of the new value is guaranteed. Could you be more concrete instead of reading morals? -- Std-Discussion mailing list Std-Discussion_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion