Date: Wed, 10 Jun 2026 17:49:17 +0000
> 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]> on behalf of Thiago Macieira via Std-Discussion <std-discussion_at_[hidden]>
Sent: Wednesday, June 10, 2026 5:44:44 PM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Thiago Macieira <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.
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]> on behalf of Thiago Macieira via Std-Discussion <std-discussion_at_[hidden]>
Sent: Wednesday, June 10, 2026 5:44:44 PM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Thiago Macieira <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 - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-06-10 17:49:22
