Question

First, I’m assuming that calling any function of std::chrono is guaranteed to be thread-safe (no undefined behaviour or race conditions or anything dangerous if called from different threads). Am I correct?

Next, for example on windows there is a well known problem related to multi-core processors that force some implementations of time related systems to allow forcing a specific core to get any time information.

What I want to know is:

1. using std::chrono, in the standard, is there any guarantee that think kind of problem shouldn’t appear?
2. or is it implementation defined
3. or is there an explicit absence of guarantee that imply that on windows you’d better get time always from the same core?

Answer 1

Yes, calls to some_clock::now() from different threads should be thread safe.

As regards the specific issue you mention with QueryPerformanceCounter, it is just that the Windows API exposes a hardware issue on some platforms. Other OSes may or may not expose this hardware issue to user code.

As far as the C++ standard is concerned, if the clock claims to be a “steady clock” then it must never go backwards, so if there are two reads on the same thread, the second must never return a value earlier than the first, even if the OS switches the thread to a different processor.

For non-steady clocks (such as std::chrono::system_clock on many systems), there is no guarantee about this, since an external agent could change the clock arbitrarily anyway.

With my implementation of the C++11 thread library (including the std::chrono stuff) the implementation takes care to ensure that the steady clocks are indeed steady. This does impose a cost over and above a raw call to QueryPerformanceCounter to ensure the synchronization, but no longer pins the thread to CPU 0 (which it used to do). I would expect other implementations to have workarounds for this issue too.

The requirements for a steady clock are in 20.11.3 [time.clock.req] (C++11 standard)