wt., 19 lip 2022 o 12:01 language.lawyer--- via Std-Discussion
<std-discussion_at_[hidden]> napisał(a):
>
> On 19/07/2022 14:00, Andrey Semashev via Std-Discussion wrote:
> > On 7/19/22 11:01, language.lawyer_at_[hidden] wrote:
> >> Yes, the invocation of notify_one happens-after the store in the
> >> non-main thread.
> >> notify_one «Unblocks the execution of at least one atomic waiting
> >> operation...»
> >> (https://timsong-cpp.github.io/cppwp/n4861/atomics.types.operations#32)
> >> The waiting thread «Blocks until it is unblocked by an atomic notifying
> >> operation»
> >> (https://timsong-cpp.github.io/cppwp/n4861/atomics.types.operations#30.3)
> >>
> >> So, now, what is the relation between the invocation of notify_one and
> >> the unblock of the waiting thread?
> >
> > I have said this before:
> >
> > http://eel.is/c++draft/atomics#wait-4
> >
> > <quote>
> > 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.
> > </quote>
> >
> > Here, X is the initial initialization of the atomic to false, Y is the
> > store of true. This says that the wait is eligible to be unblocked by
> > the notify (and it will return if the effects of Y satisfies the wait
> > condition).
> >
> >> Does it synchronize-with it? Does
> >> https://timsong-cpp.github.io/cppwp/n4861/atomics.types.operations#30.3
> >> happen-after the invocation of notify_one in any other way? If not, then
> >> why
> >> https://timsong-cpp.github.io/cppwp/n4861/atomics.types.operations#30.3
> >> must observe the new value?
> >
> > The waiting thread is unblocked and observes the new value. It must not
> > get never unblocked because it contradicts the "eligible to be
> > unblocked" requirement between the notify and wait. It cannot be
> > unblocked and not observe the store because it contradicts the
> > "happens-before" requirement between the store and notify.
>
> AYYYYYYYYYYYYYYYYYYY LMAO. Now I got. xDDDDDDDDDDDDDDDDD
>
> «eligible to be unblocked» is not a *requirement*, it is just a term. No, it does not mean «guaranteed to return from wait()».
> A term is like a handle. Its textual representation has no meaning per se. You can replace «eligible to be unblocked» with e.g. «hairy» everywhere, like:
> > A call to an atomic waiting operation on an atomic object M is /hairy/ for a call to an atomic notifying operation on M if there exist side effects X and Y on M such that...
> > notify_one() /Effects/: Unblocks the execution of at least one atomic waiting operation that is /hairy/ ([atomics.wait]) for this call ...
>
> and this changes nothing materially.

it's not term but definition that is used further:

"Effects: Unblocks the execution of at least one atomic waiting
operation on *ptr that is eligible to be unblocked ([atomics.wait]) by
this call, if any such atomic waiting operations exist."

And now its requirement.



> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion