On 18/07/2022 23:29, Andrey Semashev via Std-Discussion wrote:
> On 7/18/22 20:40, Nate Eldredge wrote:
>> On Mon, 18 Jul 2022, Andrey Semashev via Std-Discussion wrote:
>>
>>> On 7/18/22 17:48, Nate Eldredge via Std-Discussion wrote:
>>
>>>> Suppose that `b.wait(false)` starts while the value of `b` is still
>>>> `false`, and so it blocks. When `b.notify_one()` executes, the main
>>>> thread will unblock and test the value of `b`. However, I cannot find
>>>> anything to clearly imply that the store of `true` to `b` will be
>>>> visible by then. If the main thread loads the old value `false`, it
>>>> will block again, and potentially never wake up (unless there is a
>>>> spurious unblock).
>>>
>>> What you're saying is only possible if notify_one is observed before the
>>> store by the main thread. And that is not possible as the store is
>>> sequenced-before the notify. Consequently, the store happens-before the
>>> notify:
>>>
>>> http://eel.is/c++draft/intro.multithread#intro.races-10
>>
>> I agree that the store happens-before notify_one() by sequencing, but I
>> don't see how that helps by itself. What we need is for the store in
>> thr1 to happen-before the load inside b.wait() in the main thread.
>> Since these are in separate threads, sequencing alone cannot get us that
>> relation.
>
> If the store is not observed by the load then wait blocks until
> notify_one. Note that this load-test-and-block is atomic. Then the
> notify_one will unblock the wait when it happens.
>
> If you're asking whether the standard guarantees that loads observe the
> stores then this is guaranteed here:
>
> http://eel.is/c++draft/atomics.order#3

How does this apply to notifications? They are not modifications of the atomic object.
store is sequence before notify_one (in the non-main thread). Does it mean it is coherence-ordered before? No.