On 20/07/2022 13:17, Marcin Jaczewski wrote:
> How could it be possible that after unblocking it loads old value?

Do you want me to describe a hypothetical implementation? Ok.
Weak cache model. The main thread is on Core 0, the non-main one on Core 1. Each having own L1 cache. The main thread loads false and blocks by putting Core 0 into sleep state.
The non-main thread writes true, which only lives in its L1 cache, calls `notify`, which sends IPI to Core 0, the main thread wakes up, reads false from its L1 cache and blocks again.

Ofc, the non-main thread could "publish" its L1 cache or the main thread could ask for update, but why do they have to do it, from the C++ abstract machine POV? What they violate if they don't do it?

> load is atomic and value is already changed

What does "value already changed" mean? That there is assignment of "true" in the modification order of the atomic object& Yes, there is. But each thread has right to move through the modification order of an atomic object at their own pace, unless it is constrained by some coherence relations.

> as it "happens before" a call to `notify`.

And how the unblock of the waiting thread is related to the call to `notify`? Does it synchronize with it, like mutex unlock with lock (https://timsong-cpp.github.io/cppwp/n4861/thread.mutex.requirements.mutex#11)?