Date: Tue, 19 Jul 2022 09:52:33 +0100
> if the wait is woken by the notify there is no way it doesn't
> observe the store.
Suppose you have
```
X=0, Y=0
T1:
X.store(1, relaxed);
Y.store(1, relaxed);
T2:
while Y.load(relaxed) != 1 {}
r = X.load(relaxed);
```
T1's Y.store is coherence ordered before the last Y.load in T2's loop. This
does not mean r==1. If you run this on a real ARM CPU you can absolutely
observe r==0.
Andy
On Tue, 19 Jul 2022, 07:43 Andrey Semashev via Std-Discussion, <
std-discussion_at_[hidden]> wrote:
> On 7/19/22 04:59, language.lawyer_at_[hidden] wrote:
> > On 18/07/2022 23:29, Andrey Semashev via Std-Discussion wrote:
> >> On 7/18/22 20:40, Nate Eldredge wrote:
> >>> On Mon, 18 Jul 2022, Andrey Semashev via Std-Discussion wrote:
> >>>
> >>>> On 7/18/22 17:48, Nate Eldredge via Std-Discussion wrote:
> >>>
> >>>>> Suppose that `b.wait(false)` starts while the value of `b` is still
> >>>>> `false`, and so it blocks. When `b.notify_one()` executes, the main
> >>>>> thread will unblock and test the value of `b`. However, I cannot
> find
> >>>>> anything to clearly imply that the store of `true` to `b` will be
> >>>>> visible by then. If the main thread loads the old value `false`, it
> >>>>> will block again, and potentially never wake up (unless there is a
> >>>>> spurious unblock).
> >>>>
> >>>> What you're saying is only possible if notify_one is observed before
> >>>> the
> >>>> store by the main thread. And that is not possible as the store is
> >>>> sequenced-before the notify. Consequently, the store happens-before
> the
> >>>> notify:
> >>>>
> >>>> http://eel.is/c++draft/intro.multithread#intro.races-10
> >>>
> >>> I agree that the store happens-before notify_one() by sequencing, but I
> >>> don't see how that helps by itself. What we need is for the store in
> >>> thr1 to happen-before the load inside b.wait() in the main thread.
> >>> Since these are in separate threads, sequencing alone cannot get us
> that
> >>> relation.
> >>
> >> If the store is not observed by the load then wait blocks until
> >> notify_one. Note that this load-test-and-block is atomic. Then the
> >> notify_one will unblock the wait when it happens.
> >>
> >> If you're asking whether the standard guarantees that loads observe the
> >> stores then this is guaranteed here:
> >>
> >> http://eel.is/c++draft/atomics.order#3
> >
> > How does this apply to notifications? They are not modifications of the
> > atomic object.
> > store is sequence before notify_one (in the non-main thread). Does it
> > mean it is coherence-ordered before? No.
>
> It means the store happens-before notify_one (in the non-main thread).
>
> Coherence-ordered before is the relation between the store and the wait
> in the two threads. It says that when the store is coherence-ordered
> before the wait in the modification order of the atomic, the wait will
> observe the effects of the store. And since the store happens-before the
> notify, if the wait is woken by the notify there is no way it doesn't
> observe the store.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
> observe the store.
Suppose you have
```
X=0, Y=0
T1:
X.store(1, relaxed);
Y.store(1, relaxed);
T2:
while Y.load(relaxed) != 1 {}
r = X.load(relaxed);
```
T1's Y.store is coherence ordered before the last Y.load in T2's loop. This
does not mean r==1. If you run this on a real ARM CPU you can absolutely
observe r==0.
Andy
On Tue, 19 Jul 2022, 07:43 Andrey Semashev via Std-Discussion, <
std-discussion_at_[hidden]> wrote:
> On 7/19/22 04:59, language.lawyer_at_[hidden] wrote:
> > On 18/07/2022 23:29, Andrey Semashev via Std-Discussion wrote:
> >> On 7/18/22 20:40, Nate Eldredge wrote:
> >>> On Mon, 18 Jul 2022, Andrey Semashev via Std-Discussion wrote:
> >>>
> >>>> On 7/18/22 17:48, Nate Eldredge via Std-Discussion wrote:
> >>>
> >>>>> Suppose that `b.wait(false)` starts while the value of `b` is still
> >>>>> `false`, and so it blocks. When `b.notify_one()` executes, the main
> >>>>> thread will unblock and test the value of `b`. However, I cannot
> find
> >>>>> anything to clearly imply that the store of `true` to `b` will be
> >>>>> visible by then. If the main thread loads the old value `false`, it
> >>>>> will block again, and potentially never wake up (unless there is a
> >>>>> spurious unblock).
> >>>>
> >>>> What you're saying is only possible if notify_one is observed before
> >>>> the
> >>>> store by the main thread. And that is not possible as the store is
> >>>> sequenced-before the notify. Consequently, the store happens-before
> the
> >>>> notify:
> >>>>
> >>>> http://eel.is/c++draft/intro.multithread#intro.races-10
> >>>
> >>> I agree that the store happens-before notify_one() by sequencing, but I
> >>> don't see how that helps by itself. What we need is for the store in
> >>> thr1 to happen-before the load inside b.wait() in the main thread.
> >>> Since these are in separate threads, sequencing alone cannot get us
> that
> >>> relation.
> >>
> >> If the store is not observed by the load then wait blocks until
> >> notify_one. Note that this load-test-and-block is atomic. Then the
> >> notify_one will unblock the wait when it happens.
> >>
> >> If you're asking whether the standard guarantees that loads observe the
> >> stores then this is guaranteed here:
> >>
> >> http://eel.is/c++draft/atomics.order#3
> >
> > How does this apply to notifications? They are not modifications of the
> > atomic object.
> > store is sequence before notify_one (in the non-main thread). Does it
> > mean it is coherence-ordered before? No.
>
> It means the store happens-before notify_one (in the non-main thread).
>
> Coherence-ordered before is the relation between the store and the wait
> in the two threads. It says that when the store is coherence-ordered
> before the wait in the modification order of the atomic, the wait will
> observe the effects of the store. And since the store happens-before the
> notify, if the wait is woken by the notify there is no way it doesn't
> observe the store.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Received on 2022-07-19 08:52:44