wt., 19 lip 2022 o 13:39 <language.lawyer_at_[hidden]> napisał(a):
>
> 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?

And how do I do anything else when you refuse to accept things that
the standard says?

Lets quote standard again:
"""
A call to an atomic waiting operation on an atomic object M is
eligible to be unblocked by a call to an atomic notifying operation on
M if there exist side effects X and Y on M such that
- the atomic waiting operation has blocked after observing the result of X,
- X precedes Y in the modification order of M, and
- Y happens before the call to the atomic notifying operation.
"""
First observation is that there is NO direct ordering between waiting
and notifying. It looks like it should work even if `notify` is
strictly BEFORE the block.
This mean we could have sequence:

Thread1 //--// Thread2
store(M, false) //--//
...
...
load(M) == false //--//
                    //--// store(M, true)
                    //--// notify(M)
block(M, false) //--//

`block` is eligible for unblocking as it fulfills every point there.
Thread1 blocked after observing the old value `false`, Thread2 changed
`M` to `true` and then called `notify`.
Nothing prevents `notify` to unlock future `block` as only the
proceeding of modification of `M` is required.
And this could be implemented by sleeping for 1s in `notify` to give
time to all `block` correctly registered.