I don’t know what you mean.

The "as-if" rule is not an implementation detail. I don’t know what do you think the "as-if" rule is if not a part of the “abstract machine”.
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.
So, it’s only a matter of implementation of “std::chrono::steady_clock::now()”, if it issues hardware instructions to force an instruction sequence then time consistency is guaranteed, if it doesn’t then it is not.
And in that case if now1 < now2 there is no guarantee that val.load( relaxed ); will get you a 1. And this is because if you don’t tell the CPU to behave in a certain way it doesn’t have to. This is not a C++ thing.

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

As I said in this subject, we only talk about the question in the abstract machine. So, how `std::chrono::steady_clock::now()` behaves is only according to the relevant rules.

In general “temporal order of execution” is not a guaranteed thing, only “observable effects will be as-if in order in restricted circumstances” are guaranteed, but there are some functions/features to explicitly ensure that certain things happen in a particular order.

Again, "as-if" only applies to conforming implementations. We're talking about the case in the C++ abstract machine. This is like we talked about "sequence-before" in the abstract machine and concluded what the observable behavior should be based on the original structure. In this process, we don't need to consider reordering; that's the matter of implementations under the "as-if" rule.

On Wed, Jun 10, 2026 at 7:40 PM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
For your example, “it depends”, on how std::chrono::steady_clock::now() is implemented.

In general “temporal order of execution” is not a guaranteed thing, only “observable effects will be as-if in order in restricted circumstances” are guaranteed, but there are some functions/features to explicitly ensure that certain things happen in a particular order.

This has been a thing for a while now, and it’s not even just because of the language, but also because of out of order execution in modern cpu design.

From: Std-Discussion <std-discussion-bounces_at_[hidden]<mailto:std-discussion-bounces_at_[hidden]>> On Behalf Of jim x via Std-Discussion
Sent: Wednesday, June 10, 2026 11:47
To: jim x via Std-Discussion <std-discussion_at_[hidden]<mailto:std-discussion_at_[hidden]>>
Cc: jim x <xmh970252187_at_[hidden]<mailto:xmh970252187_at_[hidden]>>
Subject: [std-discussion] Does the C++ abstract machine recognize a temporal order of execution?

Consider this example:
````cpp
#include <atomic>
#include <chrono>
#include <thread>

uint64_t timestamp() {
    auto now = std::chrono::steady_clock::now().time_since_epoch();
    return std::chrono::duration_cast<std::chrono::nanoseconds>(now).count();
}

int main() {
    std::atomic<long int> val = 0;
    long int now1, now2;
    auto t1 = std::thread([&]() {
        val.store(1,relaxed); // #1
        now1 = timestamp(); // #2
    });
    auto t2 = std::thread([&]() {
        now2 = timestamp(); // #3
        val.load( relaxed ); // #4
    });
    t1.join();
    t2.join();
}
````
This question arises from whether we can determine if a specific execution outcome is caused by inter-thread latency within the abstract machine. A possible execution of the above example is that #4 reads 0 even when now1 < now2.

Both intro.execution p8<https://eel.is/c++draft/intro.execution#8>
> Given any two evaluations A and B, if A is sequenced before B (or, equivalently, B is sequenced after A), then the execution of A shall precede the execution of B.

and [stmt.pre] p1
> Except as indicated, statements are executed in sequence ([intro.execution]).

state that the control flow executes expressions in sequential order within a single thread, provided one evaluation is sequenced before another.

Furthermore, [time.clock.steady] p1 states:
> Objects of class steady_clock represent clocks for which values of time_point never decrease as physical time advances and for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted.

and [time.clock.req] p2 states:
> C1::now(): Returns a time_point object representing the current point in time.

This implies that calling now() samples a global time point when the control flow executes it. Since the control flow cannot reach #2 without first executing #1, #1 must be executed by the control flow at a point in time no later than the time point returned by #2. The same logic applies to #3 and #4.

Therefore, when now1 < now2, does it imply that #1 is executed by the control flow of t1 at a point in time strictly earlier than when #4 is executed by the control flow of t2, from the perspective of the abstract machine? (Note that this does not refer to a happens-before relationship, but rather a temporal comparison of the control flows executing these expressions.)

As a minor clarification, this is not a question about physical implementations (which are governed by the "as-if" rule), but rather a conceptual question about the formal behavior defined by the C++ abstract machine.

The deduction above is based entirely on existing rules within the standard, and there seems to be no explicit rule that contradicts this interpretation. Consequently, this appears to be a gray area in the specification. If this reasoning is indeed flawed, where exactly does the flaw lie? Furthermore, are there any specific rules in the standard that would directly negate this conclusion?