Non-monotonic behavior of std::chrono::steady_clock

[Urmeli0815]

We use emsdk 2.0.17 and have a function in C++ that uses std::chrono::steady_clock like this:

uint64_t GetNow()
{
	using namespace std::chrono;
	return static_cast<uint64_t>(duration_cast<milliseconds>(steady_clock::now().time_since_epoch()).count());
}

According to the C++-Standard the return value should be a monolitically increasing number, independent of the thread on which it is called. We currently experience problems with non-monotonic behavior between two subsequent GetNow()-Calls on different threads, partially with quite substantial negative differences.

A while ago an issue was fixed in this area: #9783. My question would be if this fix only resolved the problem between the mainthread and a pthread, or should it also resolve it between pthreads?

[kripken]

I think that PR fixed the sync during startup of threads relative to the main thread. And I think you are right that there may be a lack of sync between threads.

To fix this, I suspect we'd need to proxy all time measurements to the main thread. That will add a very high cost, however, But it might be worth investigating if doing so just for monotonic timers is acceptable.

[Urmeli0815]

Thank you very much for the fast answer!

steady_clock behaving in a non-standard way in our cross-platform code base is problematic and we only found out by accident. I think it would be better then to not provide it at all and produce a compile error.

If it helps: we are currently trying to mitigate the problem using emscripten_date_now() instead. It improves on the problem in that it is monotonic between threads but afaik it is vulnerable to changes of the system clock.

[kripken]

I see. This is worth trying to fix, I agree.

To investigate, I'd suggest looking in libc++ to find what lower-level API steady_clock uses. Then we can try to estimate the cost of adding proxying to it.

[dsamo]

Is this still possible after @RReverser 's improvement of the clock drift compensation? I have been following this issue since it was created and there seems to have been quite the progress here but I am wondering why this is still open.

Is it still possible that two threads calling performance.timeOrigin + performance.now() can still experience non monotonic behavior?

[RReverser]

Is this still possible after @RReverser 's improvement of the clock drift compensation?

Hm yeah I believe it should've fixed this issue but would be nice if someone confirmed. As I said in that PR:

Unlike custom __performance_now_clock_drift sent as a message to a worker, it won't suffer from the small time difference incurred by postMessage itself, making synchronisation more precise

which sounds like fixing the root cause that was causing the cross-thread discrepancies.

[sbc100]

OK, closing. We can re-open if anyone finds further problems.