On Wednesday, 10 June 2026 10:49:17 Pacific Daylight Time Tiago Freire 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.

Yes and I agree not what was being discussed.

An inconsistent monotonic clock could show up as a "clock went backwards" if
the thread got de-scheduled from one computing device and scheduled in
another. The window of time this could happen is very small, and context-
switching is usually pretty costly, but never say never.

The amount of silicon area and resources on Intel processors dedicated to
ensuring that the time stamp counters are kept monotonic and clock-
independent, and yet quick to access, is massive. I don't know about other
architectures, but it has to be similar.

However, while the inconsistent clock itself was not the point, the
*consistency* of reading a clock was.

> 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.

That depends on the sequence of happens-before relationships. We have a very
large section of the Standard dedicated to explaining this.

What is missing is whether there is any happens-before of any kind relating to
the steady_clock. I think there should be.

> 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.

I've pointed out one example. And while I think it is necessary for there to
be a happens-before via release/acquire, I am not so certain all
implementations do it properly.

> 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.

Reordering, yes.

The question is back to the point of the OP: is a happens-before relationship
required? The Standard doesn't say anything.

I think it should. Therefore, reordering is permitted, so long as the observed
external behaviour is that of the happens-before sequence.

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