śr., 20 lip 2022 o 09:55 <language.lawyer_at_[hidden]> napisał(a):
>
> On 20/07/2022 00:22, Marcin Jaczewski wrote:
> > 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.
>
> And how all this resolves the initial concern that a thread is not guaranteed to see the new value after unblock and thus will block again?

How could it be possible that after unblocking it loads old value?
load is atomic and value is already changed as it "happens before" a
call to `notify`.