2

I have 2 processes (not threads) that are supposed to read the system clock at the same time. For this purpose, the first process uses 

QTime::currentTime();

and the second process uses 

std::chrono::high_resolution_clock::now();

But when I read the respective clock values read by these 2 processes, I find that there's always a difference of a few microseconds. Is it because the system clock is a shared resource, so one has to wait for the other to finish reading? Is it because the functions that read the system clock are not the same, so the time resolution is not the same? (but this seems very unlikely to me... because in my understanding the time resolution is set by the RTC, not the high level APIs)

I do not use any specific 'measure' to synchronize these 2 processes. The first is constantly attempting to read the system clock (it has a while(1)), the second reads the system clock when I launch it. So because the first process is always attempting to read the system clock, I guess there will probably be a 'race condition' when process 2 attempts the read the clock.

S.E.K.
  • 147
  • 2
  • 11
  • 2
    How are you coordinating the two processes to attempt to read at exactly the same time to begin with? – jingx Oct 14 '19 at 15:56
  • @jingx I edited my post to answer your question – S.E.K. Oct 14 '19 at 16:27
  • 1
    This is nothing to do with what are usually known as *race conditions*, such as one process having to wait for another to free a resource. This simply demonstrates the effective impossibility of observing two events at *exactly* the same time, where *exactly* is defined by the resolution of a modern computer clock. – High Performance Mark Oct 14 '19 at 16:40
  • Let's agree that **explicit and repeatable MCVE-formulated experiment** is a way to go, instead of fuzzy, opinionated hypotheses - so better than saying *"I guess there will probably be..."* **define a test** perhaps coded right on a commonly available platform - like on https://godbolt.org/z/ZVnO6R or similarly on https://tio.run/# ( having 680+ compiled / interpreted languages there ) --- and we all start to get a common ground to test a { **[PASS] | [FAIL]** }-scenario and promote any improved solution for the original problem --- that's fair to be both repeatable & quantitative, isn't it? – user3666197 Oct 14 '19 at 16:48

1 Answers1

0

There is only a race condition in the sense that you can not predict which process will report an earlier time, or if they will report the same time. No harm is done by (near) simultaneous reads of the clock. Both reports will be accurate to within the ability of the OS to deliver the information. Depending on the OS, and hardware, it may or may not be possible for the two processes to report the same time.

It may or may not be a shared resource. It might not even be the same clock under the hood. std::chrono::high_resolution_clock is typically a typedef to either std::chrono::steady_clock or std::chrono::system_clock, and which one it is varies by platform. On macOS/iOS/watchOS high_resolution_clock is a typedef to steady_clock and counts nanoseconds since the system booted. This measure has no relationship to the time of day, or date on the calendar.

There is a description of the difference between steady_clock and system_clock here.

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577