CODEWITHSUNDEEP
c++c++11std
Klaim
Klaim

Reputation: 69732

Is there any std::chrono thread safety guarantee even with multicore context?

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?

Upvotes: 17

Views: 8792

Answers (2)

Anthony Williams
Anthony Williams

Reputation: 68631

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)

Upvotes: 7

David Schwartz
David Schwartz

Reputation: 182799

I honestly believe that this question is fully answered by the follow statement: There is no guarantee that an implementation will not have platform-specific bugs. It's all supposed to work perfectly, but sometimes for some reason or another it doesn't. Nobody can promise you that it will do what you want, but it is supposed to work.

Upvotes: -2

Related Questions