3

Using boost::chrono::steady_clock or std::chrono::steady_clock is suppose to guarantee that physical time is always monotonic and is not affected by date time changes in the system. Here is my question, if I have two processes that need to be immune to system date time changes, is it enough to exchange just the time_since_epoch? In other words, the time interpretation of the two processes to the same time since epoch will be the same? Specifically I need to answer this question for Windows and QNX.

EDIT: Both processes are running in the same computer, same operating system and communicate via IPC calls.

Darien Pardinas
  • 5,910
  • 1
  • 41
  • 48

4 Answers4

3

No the times are not interchangeable between systems, because C++ doesn't specify the epoch. The epoch is depending on the operating system, different systems can have different epochs.

If, on the other hand, you share the times only locally, within the same system, then it's okay.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
2

C++ standard says about steady_clock:

20.12.7.2 Class steady_clock [time.clock.steady]

Objects of class steady_clock represent clocks for which values of time_point never decrease as physical time advances and for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted.

Compare this to what the standard has to say about system_clock:

20.12.7.1 Class system_clock [time.clock.system]

Objects of class system_clock represent wall clock time from the system-wide realtime clock.

There's no mention about steady_clock being "system-wide", which leads me to believe that, according to the C++ standard, you cannot trust on two steady_clocks in different processes on the same machine having the same epoch.

khuttun
  • 683
  • 1
  • 4
  • 14
2

Old, but maybe someone will benefit... Probably, as we understood, it isn't defined by the C++ standard, so it depends on your compiler/system/stdlib implementation.

Eg.: If the implementation uses CLOCK_MONOTONIC from Linux (https://man7.org/linux/man-pages/man2/clock_gettime.2.html):

CLOCK_MONOTONIC

A nonsettable system-wide clock that represents monotonic time since—as described by POSIX—"some unspecified point in the past". On Linux, that point corresponds to the number of seconds that the system has been running since it was booted.

It's a system-wide clock then.

ouflak
  • 2,458
  • 10
  • 44
  • 49
DeZee
  • 95
  • 6
  • This answer, while not exactly pertaining to the OP (specifically, this answer is "yes" while the correct answer is "no"), it is interesting and provides valuable information about your options (if you are using Linux), so I upvoted. – Guss Jul 31 '22 at 12:05
  • @Guss why is the correct answer "no"? Is it because the standard doesn't specify the epoch or system-wideness? – starriet Oct 08 '22 at 13:45
  • @starriet: The OP question was "Is the epoch related to some local arbitrary start time", while correctly is "undefined, so ", all implementations I've seen use a specific absolute point in time as the epoch (i.e. not relative to an arbitrary local start time). Or more generally - for any single implementation, the epoch will be identical across restarts of system. Specifically, the C++ `std::chrono::steady_clock` is completely unrelated to the Linux specific `CLOCK_MONOTONIC` `clockid` for the POSIX `clock_gettime()` API referred in the example (in specification, if not in implementation). – Guss Oct 08 '22 at 15:51
  • @Guss Thanks. Let me check if I got you correctly. 1) Your expression "local arbitrary" means each process can have a *different* epoch. 2) when you said "correct answer is no", you mean it's undefined in the C++ specification, but in typical implementations the epoch will be identical to any process. (This is also what I thought before, but let me know if I got you wrong). P.S.: OP's main question is whether multiple processes running in the same system share the same epoch or not, and I hope we thought in the same way. – starriet Oct 09 '22 at 00:53
  • @starriet I did some more research and I take back everything I've said - the correct answer is "yes": all implementations I've seen implement `steady_clock` using exactly or some variation of `clock_gettime(CLOCK_MONOTONIC)` (I checked GCC's and LLVM's on various platforms and MSVCC's for Windows). In my original comment I likely confused `stead_clock` with `system_clock`. This means that using the same implementation on the same system with the same boot time, then you can just look at `time_since_epoch`, but the last requirement is a doozy - you can't store the value across system restarts. – Guss Oct 09 '22 at 08:03
0

@DeZee mentioned Linux implementation - the epoch is when the system boots.

How about Windows?

MSVC uses QueryPerformanceCounter and QueryPerformanceFrequency for its std::chrono::steady_clock implementation. And from MSDN (emphasis mine):

In general, the performance counter results are consistent across all processors in multi-core and multi-processor systems, even when measured on different threads or processes.

(the doc also mentions some exceptions, so please see it)

And:

The frequency of the performance counter is fixed at system boot and is consistent across all processors so you only need to query the frequency from QueryPerformanceFrequency as the application initializes, and then cache the result.

Also, in the code of the std::chrono::steady_clock implementation of MSVC, we can see this comment:

const long long _Freq = _Query_perf_frequency();    // doesn't change after system boot

Now, your question is:

the time interpretation of the two processes to the same time since epoch will be the same?

So the answer to your question would be "yes", at least for Linux and Windows.

starriet
  • 2,565
  • 22
  • 23