> What I mean is whether expressions executed sequentially by the control flow also follow a chronological order—that is, if A is sequenced before B, then the execution of A occurs no later than the execution of B.

Neither your compiler nor your cpu respects that and the standard at least implicitly acknowledges this.

________________________________
From: jim x <xmh970252187_at_[hidden]>
Sent: Thursday, June 11, 2026 4:33:15 AM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-discussion] Does the C++ abstract machine recognize a temporal order of execution?

I think the point being discussed here is if you have a thread X where you write the code to do A then B, and you have a thread Y where you write code to do C then D, if you can deduce that C happened after B is it guaranteed that D happened after A?

No, I didn't talk about the happens-before relationship here; the happens-before defines the visibility. That is, I didn't say `#1` should be visible to `#4` because the execution of `#1` is earlier than the execution of `#4` in time.

I only talk about the semantics in the abstract machine. What I mean is whether expressions executed sequentially by the control flow also follow a chronological order—that is, if A is sequenced before B, then the execution of A occurs no later than the execution of B. Since in this case B is now(), which returns the value representing the current time point, if the previous statement is true, then we could infer that the execution A occurs no later than the time point represented by the value now() returns.

On Thu, Jun 11, 2026 at 1:49 AM Tiago Freire via Std-Discussion <std-discussion_at_[hidden]<mailto:std-discussion_at_[hidden]>> wrote:
> Inconsistent monotonic clocks are a bug in the platform implementation and a violation of the Standard that should be fixed by said implementation.

Is it? Regardless, I don't think this is the point being discussed here.

I think the point being discussed here is if you have a thread X where you write the code to do A then B, and you have a thread Y where you write code to do C then D, if you can deduce that C happened after B is it guaranteed that D happened after A?

And the answer to that question is No.

For the particular case of reading a clock, I assume that on most implementations a barrier would be involved somewhere, and as you have seemed to correctly point out in a separate email.

But an implementation where reading a clock would still allow for other instructions around it to be reordered before or after the read, looks to me too also be a valid implementation.



________________________________
From: Std-Discussion <std-discussion-bounces_at_[hidden]<mailto:std-discussion-bounces_at_[hidden]>> on behalf of Thiago Macieira via Std-Discussion <std-discussion_at_[hidden]<mailto:std-discussion_at_[hidden]>>
Sent: Wednesday, June 10, 2026 5:44:44 PM
To: std-discussion_at_[hidden]<mailto:std-discussion_at_[hidden]> <std-discussion_at_[hidden]<mailto:std-discussion_at_[hidden]>>
Cc: Thiago Macieira <thiago_at_[hidden]<mailto:thiago_at_[hidden]>>
Subject: Re: [std-discussion] Does the C++ abstract machine recognize a temporal order of execution?

On Wednesday, 10 June 2026 07:08:36 Pacific Daylight Time Tiago Freire via Std-
Discussion wrote:
> Regardless of what you think the “abstract machine” is, I have raised you
> the practical problem that time consistency is not a thing that still exist
> and it doesn’t matter what language you are talking about, either it be
> C++, C, Rust, assembly, because CPUs no longer work like that.

Inconsistent monotonic clocks are a bug in the platform implementation and a
violation of the Standard that should be fixed by said implementation. If an
application does run on such a platform, it may need to work around platform
bugs. This is no different than any other bugs or conformance failures.

But Jim is asking what the Standard says should happen, independent of bugs.
It's difficult to discuss bugs when we don't agree what the bug-free behaviour
should be.

--
Thiago Macieira - thiago (AT) macieira.info<http://macieira.info> - thiago (AT) kde.org<http://kde.org>
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.

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