>
> Isn't "occurs in no later time point than the time point it executes a
> later expression" the definition of "happens-before"?


No, "happens-before" is strictly defined in [intro.races] p7, and it
describes the visibility. However, the control flow executing an expression
occurring at no later time point than when it executes another expression
doesn't mean the previous expression *happens-before* the later expression.
In other words, "happens-before" defines the observable behavior while
"occurs in no later time point" just talks about the semantics in the
abstract machine.

On Thu, Jun 11, 2026 at 2:15 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:

> > This is the misunderstanding of the OP. The OP doesn't talk about the
> happens-before relationship; instead, the intention can be simplified as
> talking about whether the control flow executing a previous expression
> occurs in no later time point than the time point it executes a later
> expression.
>
> Isn't "occurs in no later time point than the time point it executes a
> later expression" the definition of "happens-before"?
>
>
> ------------------------------
> *From:* Std-Discussion <std-discussion-bounces_at_[hidden]> on
> behalf of jim x via Std-Discussion <std-discussion_at_[hidden]>
> *Sent:* Thursday, June 11, 2026 7:52:10 AM
> *To:* std-discussion_at_[hidden] <std-discussion_at_[hidden]>
> *Cc:* jim x <xmh970252187_at_[hidden]>
> *Subject:* Re: [std-discussion] Does the C++ abstract machine recognize a
> temporal order of execution?
>
>
> What exactly would you be establishing a happens-before relationship with
> in the original example?
>
>
> This is the misunderstanding of the OP. The OP doesn't talk about the
> happens-before relationship; instead, the intention can be simplified as
> talking about whether the control flow executing a previous expression
> occurs in no later time point than the time point it executes a later
> expression.
>
> On Thu, Jun 11, 2026 at 1:37 PM Jennifier Burnett via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
> An acquire barrier is meaningless in this context. An acquire barrier
> needs either a release operation or atomic operation preceded by a release
> barrier to have any semantics beyond relaxed. What exactly would you be
> establishing a happens-before relationship with in the original example?
> Assuming the call to now() is an implicit acquire barrier changes nothing
> about the semantics because there's no corresponding release for it to
> establish a happens-before relationship with. The first thread doesn't even
> have any operations other than the call to now() that the acquire barrier
> would apply to
>
> On 11 June 2026 01:37:42 BST, Thiago Macieira via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >On Wednesday, 10 June 2026 16:24:30 Pacific Daylight Time Simon Cooke
> wrote:
> >> If you don't want that, you need acquire semantics, which will prevent
> the
> >> write from down after the timestamp() call in #2
> >
> >This is the essence of the argument: reading from the monotonic clock
> should
> >be an acquire barrier. The Standard does not say it is, but I think it
> should.
> >
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
>