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.