当 2 个进程尝试同时读取系统时钟时是否存在竞争条件？答案

【问题标题】：is there a race condition when 2 processes attempt to read the system clock at the same time?当 2 个进程尝试同时读取系统时钟时是否存在竞争条件？
【发布时间】：2020-02-11 06:41:56
【问题描述】：

我有 2 个进程（不是线程）应该同时读取系统时钟。为此，第一个进程使用

QTime::currentTime();

第二个进程使用

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

但是当我读取这两个进程读取的各自时钟值时，我发现总是有几微秒的差异。是不是因为系统时钟是共享资源，所以一个必须等待另一个读完？是不是因为读取系统时钟的函数不一样，所以时间分辨率不一样？（但这对我来说似乎不太可能......因为据我了解，时间分辨率是由 RTC 设置的，而不是高级 API）

我不使用任何特定的“措施”来同步这两个过程。第一个是不断尝试读取系统时钟（它有一段时间（1）），第二个在我启动它时读取系统时钟。所以因为第一个进程总是试图读取系统时钟，我猜当进程 2 尝试读取时钟时可能会出现“竞争条件”。

【问题讨论】：

您如何协调这两个进程以尝试在完全相同的时间开始阅读？
@jingx 我编辑了我的帖子来回答你的问题
这与通常称为竞态条件 无关，例如一个进程必须等待另一个进程释放资源。这只是证明了在完全同时观察两个事件实际上是不可能的，其中完全是由现代计算机时钟的分辨率定义的。
让我们同意明确和可重复的 MCVE 公式化实验是一种可行的方法，而不是模糊的、固执己见的假设 - 总比说 “我想会有可能是..." 定义一个测试 可能在一个常用平台上正确编码 - 比如在godbolt.org/z/ZVnO6R 或类似在tio.run/# 上（那里有 680 多种编译/解释语言） --- 我们都开始有共同点来测试 { [PASS] | [失败] }-场景并为原始问题推广任何改进的解决方案 --- 既可重复又可量化，不是吗？

标签： concurrency parallel-processing race-condition real-time-clock

【解决方案1】：

只有在您无法预测哪个进程将报告更早的时间，或者它们是否会报告相同的时间时，才存在竞争条件。（接近）同时读取时钟不会造成任何伤害。两种报告都将在操作系统提供信息的能力范围内准确无误。根据操作系统和硬件，两个进程可能会或可能不会同时报告时间。

它可能是也可能不是共享资源。它甚至可能不是引擎盖下的同一个时钟。 std::chrono::high_resolution_clock 通常是 typedef 到 std::chrono::steady_clock 或 std::chrono::system_clock，并且它因平台而异。在 macOS/iOS/watchOS 上，high_resolution_clock 是 typedef 到 steady_clock，自系统启动后计算纳秒。此度量与一天中的时间或日历上的日期无关。

有说明steady_clock和system_clockhere的区别。

【讨论】：