在 futex 系统调用中使用 std::atomic

如何解决在 futex 系统调用中使用 std::atomic

在 C++20 中，我们能够在原子变量上休眠，等待它们的值改变。 我们通过使用 std::atomic::wait 方法来实现。

遗憾的是，虽然 wait 已标准化，但 wait_for 和 wait_until 尚未标准化。这意味着我们不能在超时的原子变量上休眠。

无论如何，使用 Windows 上的 WaitOnAddress 和 Linux 上的 futex 系统调用在幕后实现了在原子变量上休眠。

解决上述问题（无法在具有超时的原子变量上休眠），我可以在 Windows 上将 std::atomic 的内存地址传递给 WaitOnAddress，它会（有点）工作没有 UB，因为函数将 void* 作为参数，将 std::atomic<type> 强制转换为 void*

是有效的

在 Linux 上，尚不清楚将 std::atomic 与 futex 混合是否可以。 futex 获得 uint32_t* 或 int32_t*（取决于您阅读的手册），将 std::atomic<u/int> 转换为 u/int* 是 UB。另一方面，手册说

uaddr 参数指向 futex 字。 在所有平台上， futexes 是四字节整数，必须在四位对齐 字节边界。在 futex 上执行的操作是 在 futex_op 参数中指定； val 是一个值，其含义 目的取决于 futex_op。

提示 alignas(4) std::atomic<int> 应该可以工作，并且它是哪种整数类型并不重要，只要该类型的大小为 4 个字节且对齐为 4。

此外，我已经看到很多地方实现了这种结合原子和 futex 的技巧，包括 boost 和 TBB。

那么以非 UB 方式在具有超时的原子变量上睡眠的最佳方法是什么？ 我们是否必须使用 OS 原语来实现我们自己的原子类才能正确实现它？

（存在混合原子和条件变量等解决方案，但不是最优的）

解决方法

您不一定非要实现完整的自定义 atomic API，从 atomic<T> 中简单地提取指向底层数据的指针并将其传递给系统实际上应该是安全的。

由于 std::atomic 不像其他同步原语提供的那样提供一些等效的 native_handle，因此您将不得不进行一些特定于实现的 hack 以尝试使其与本机 API 交互.

在大多数情况下，假设实现中这些类型的第一个成员与 T 类型相同是相当安全的——至少对于整数值^[1] .这是一种保证，可以提取出该值。

... 将 std::atomic<u/int> 转换为 u/int* 是 UB

事实并非如此。

std::atomic 由标准保证为 Standard-Layout Type。标准布局类型的一个有用但通常深奥的属性是 reinterpret_cast 一个 T to a value or reference of the first sub-object（例如 std::atomic 的第一个成员）是安全的。

只要我们能保证 std::atomic<u/int> 包含只 u/int 作为成员（或至少，作为它的第一个成员），那么它是完全安全的以这种方式提取类型：

auto* r = reinterpret_cast<std::uint32_t*>(&atomic);
// Pass to futex API...

在将 atomic 传递给 void* API 之前，这种方法也应该适用于 Windows 以将 T* 转换为基础类型。

注意：将 void* 指针传递给 U*，该 atomic<T>* 被重新解释为 void*（例如 T* 到 {{1 }} 当它期望 WaitOnAddress) 是未定义行为——即使有标准布局保证（据我所知）。它仍然可能工作，因为编译器看不到系统 API —— 但这并不能使代码格式良好。

注意 2：我不能谈论 void* API，因为我没有实际使用过它——但是任何依赖于正确对齐积分地址的原子 API值（C++20 或其他）应该通过提取指向基础值的指针来正常工作。

---

^[1] 由于这被标记为 static_assert，您可以使用 std::is_layout_compatible 和 static_assert(std::is_layout_compatible_v<int,std::atomic<int>>); 来验证：

is_layout_compatible

（感谢@apmccartney 在评论中提出这个建议）。

我可以确认这将与 Microsoft's STL、libc++ 和 libstdc++ 的布局兼容；但是，如果您无权访问 {{1}} 并且您使用的是不同的系统，则可能需要检查编译器的标头以确保此假设成立。