即使使用多核上下文，是不是有任何 std::chrono 线程安全保证？

Posted 2023-02-16

【中文标题】即使使用多核上下文，是不是有任何 std::chrono 线程安全保证？

【英文标题】：Is there any std::chrono thread safety guarantee even with multicore context?即使使用多核上下文，是否有任何 std::chrono 线程安全保证？

【发布时间】：2012-06-05 09:09:04

【问题描述】：

首先，我假设调用 std::chrono 的任何函数都保证是线程安全的（如果从不同的线程调用，没有未定义的行为或竞争条件或任何危险）。我说的对吗？

接下来，例如on windows there is a well known problem related to multi-core processors，即强制some implementations of time related systems to allow forcing a specific core to get any time information。

我想知道的是：

在标准中使用std::chrono，是否有任何保证不会出现think样的问题？ 或者它是实现定义的 或者是否有明确的缺乏保证意味着在 Windows 上您最好始终从同一个内核获取时间？

【问题讨论】：

那篇知识库文章描述了一个硬件问题。它与Windows没有任何关系。使用该硬件计时器的任何操作系统也会出现同样的问题。不，C++ 标准中没有任何内容说“如果您在罕见的有缺陷的硬件上运行代码，则允许此类行为不良”。

我的理解是问题只出现在Windows上？无论如何，为什么要删除您的答案？此外，这并不能回答我提出的所有问题。

看知识库文章是怎么说的：“这个操作系统的行为是设计使然。当操作系统从芯片组获取不可靠的数据时，性能计数器调整是必要的。”。它可以发生在任何操作系统上。微软只是记录它，因为人们在那里经常遇到它，因此需要一篇知识库文章（部分原因是 Windows 被广泛使用，部分原因是它被广泛用于游戏，如果更频繁地使用高分辨率计时器）

我删除了答案因为它没有回答您提出的所有问题。我觉得它更适合作为评论:)

【参考方案1】：

是的，从不同线程调用some_clock::now() 应该是线程安全的。

关于您提到的QueryPerformanceCounter 的具体问题，只是Windows API 在某些平台上暴露了硬件问题。其他操作系统可能会也可能不会将此硬件问题暴露给用户代码。

就 C++ 标准而言，如果时钟声称是“稳定时钟”，那么它绝不能倒退，因此如果在同一个线程上有两次读取，则第二次的返回值绝不能早于第一个，即使操作系统将线程切换到不同的处理器。

对于非稳定时钟（例如许多系统上的std::chrono::system_clock），对此没有任何保证，因为无论如何外部代理都可以任意更改时钟。

使用my implementation of the C++11 thread library（包括std::chrono 的东西），实现会注意确保稳定的时钟确实是稳定的。这确实会在对QueryPerformanceCounter 的原始调用之外施加成本以确保同步，但不再将线程固定到 CPU 0（它曾经这样做）。我希望其他实现也有解决此问题的方法。

稳定时钟的要求在 20.11.3 [time.clock.req]（C++11 标准）中

【讨论】：

我接受这个答案，因为它说 stable_clock 永远不应该倒退，这正是我最终需要知道的。但是，如果您可以添加对标准的引用，那就太好了。另外，我很愚蠢，没有先问你，你在提升邮件列表中，我在你的书中间...... XD

稳定时钟的要求在 20.11.3 [time.clock.req]

有谁知道在用新值重置先前值时（同时从另一个线程）

不，time_point 不是原子变量，因此您不能在不同步的情况下从另一个线程读取值的同时更改一个线程的值

获取时钟时间不需要系统调用，因此实际上不会是原子的吗？

【参考方案2】：

老实说，我相信以下陈述完全回答了这个问题：无法保证实现不会有特定于平台的错误。这一切都应该完美地工作，但有时出于某种原因，它没有。没有人可以向你保证它会做你想做的事，但它应该可以工作。