c++ - Is there any std::chrono thread safety guaranty even with multicore context? -

first, i'm assuming calling function of std::chrono guaranteed thread-safe (no undefined behaviour or race conditions or dangerous if called different threads). correct?

next, example on windows there known problem related multi-core processors force some implementations of time related systems allow forcing specific core time information.

what want know is:

1. using std::chrono, in standard, there guarantee think kind of problem shouldn't appear?
2. or implementation defined
3. or there explicit absence of guarantee imply on windows you'd better time same core?

yes, calls some_clock::now() different threads should thread safe.

as regards specific issue mention queryperformancecounter, windows api exposes hardware issue on platforms. other oses may or may not expose hardware issue user code.

as far c++ standard concerned, if clock claims "steady clock" must never go backwards, if there 2 reads on same thread, second must never return value earlier first, if os switches thread different processor.

for non-steady clocks (such std::chrono::system_clock on many systems), there no guarantee this, since external agent change clock arbitrarily anyway.

with my implementation of c++11 thread library (including std::chrono stuff) implementation takes care ensure steady clocks indeed steady. impose cost on , above raw call queryperformancecounter ensure synchronization, no longer pins thread cpu 0 (which used do). expect other implementations have workarounds issue too.

the requirements steady clock in 20.11.3 [time.clock.req] (c++11 standard)