On 7/18/22 22:04, Nate Eldredge via Std-Discussion wrote:
> On Mon, 18 Jul 2022, Marcin Jaczewski via Std-Discussion wrote:
>
>> To compare to `atomics.wait#4` we have:
>> ```
>> std::atomic<bool> b{false}; //EVENT X
>>
>> void thr1() {
>> b.store(true, std::memory_order_relaxed); //EVENT Y
>> b.notify_one(); //NOTIFY
>> }
>>
>> int main() {
>> std::thread t(thr1);
>> b.wait(false); //BLOCK
>> t.join();
>> return 0;
>> }
>> ```
>>
>> "the atomic waiting operation has blocked after observing the result
>> of X," -> this X happens before `main` start, and means should be
>> visible for block operation.
>>
>> "X precedes Y in the modification order of M, and" -> again X happens
>> before thread start
>>
>> "Y happens before the call to the atomic notifying operation." -> is
>> line before notify
>>
>> For mea this is clear that the function should unblock there.
>> Is This correct interpretation?
>
> I agree that, if the wait blocks at all, then it unblocks at least once.
> That is not the issue. But after it unblocks, it reloads the value of b
> to decide whether to return or to block again. The question is whether,
> after unblocking in response to the notify, it might load the value
> `false` and thus block again.

How is this possible, under the current ordering rules?