pon., 18 lip 2022 o 21:04 Nate Eldredge <nate_at_[hidden]> napisał(a):
>
> On Mon, 18 Jul 2022, Marcin Jaczewski via Std-Discussion wrote:
>
> > To compare to `atomics.wait#4` we have:
> > ```
> > std::atomic<bool> b{false}; //EVENT X
> >
> > void thr1() {
> > b.store(true, std::memory_order_relaxed); //EVENT Y
> > b.notify_one(); //NOTIFY
> > }
> >
> > int main() {
> > std::thread t(thr1);
> > b.wait(false); //BLOCK
> > t.join();
> > return 0;
> > }
> > ```
> >
> > "the atomic waiting operation has blocked after observing the result
> > of X," -> this X happens before `main` start, and means should be
> > visible for block operation.
> >
> > "X precedes Y in the modification order of M, and" -> again X happens
> > before thread start
> >
> > "Y happens before the call to the atomic notifying operation." -> is
> > line before notify
> >
> > For mea this is clear that the function should unblock there.
> > Is This correct interpretation?
>
> I agree that, if the wait blocks at all, then it unblocks at least once.
> That is not the issue. But after it unblocks, it reloads the value of b
> to decide whether to return or to block again. The question is whether,
> after unblocking in response to the notify, it might load the value
> `false` and thus block again. Presumably the intended behavior is that it
> must not, and my concern is that I cannot see how the standard's language
> actually implies that.
>

But this is a naive implementation of `wait` that behaves this way.
This point #4 requires the whole `wait` work correctly and needs
handling cases like this.
I could have more complex implementation, or use stronger barriers.


> --
> Nate Eldredge
> nate_at_[hidden]
>