c++ - 当外部基础类型未按要求对齐时的atomic_ref

Question

我继续阅读p0019r8以下内容:

atomic_ref(T& obj);

Requires: The referenced object shall be aligned to required_alignment.

cppreference未对齐时将其解释为 UB:

The behavior is undefined if obj is not aligned to required_alignment.

---

那么您期望实现如何处理它？<​​/strong>

并且实现可以检查编译时 alignof，但实际上，类型可能比alignof 更对齐。实现可以解释指针位并检查运行时对齐，但这是额外的运行时检查。

最终我看到以下选项:

• 什么都不做 - 以令人不快的方式实现运行时未定义的行为，仅支持正确的使用
• 检查编译时对齐 (alignof)，如果错误则发出警告
• 检查编译时对齐 (alignof)，如果错误则在编译时失败不正确，因为实际对齐可能大于静态类型可见的对齐
• 检查编译时对齐 (alignof)，如果错误则在运行时失败不正确，因为实际对齐可能大于静态类型可见的对齐
• 检查编译时对齐 (alignof)，如果错误则回退到基于锁
• 检查运行时对齐(指针位)，如果错误则运行时失败
• 检查运行时对齐(指针位)，如果错误则回退到基于锁

Answer 1

TL:DR:永远不要默默地回退到锁定，没有人希望这样做，因为它破坏了 std::atomic 目的的主要部分。 将非无锁视为可移植性的后备方案，而不是可行的操作模式。

---

UB 使得编译器简单地假设而不检查其是否对齐是合法的。无需任何运行时检查即可假设为 one of the major benefits of the concept of UB 。这是大多数人在运行时在优化构建中想要/期望的，而不是使用可能回退到使用互斥体的条件分支来使代码膨胀。

是否(以及如何)在此处定义任何行为的选择完全取决于实现，这是实现质量以及性能与调试之间权衡的问题。我认为您知道这一点，并且实际上是在询问用户希望编译器为这些 QoI 选择选择什么，这很好。

正如您链接的 P0019 提案所说，这一切都归结为 QOI 问题:

4. Reference-ability Constraints

An object referenced by an atomic reference must satisfy possibly architecture-specific constraints. For example, the object might need to be properly aligned in memory or might not be allowed to reside in GPU register memory. We do not enumerate all potential constraints or specify behavior when these constraints are violated. It is a quality-of-implementation issue to generate appropriate information when constraints are violated.

“生成适当的信息”措辞意味着他们希望实现在检测到违规时发出警告/错误，而不是回退到锁定。

尽管可能回退到锁定的实现可能会愚蠢地将 required_alignment 设置为正确性的最小值 (1)，而不是无锁的最小值。当然没有人希望这样，但这是一个 QoI 问题，而不是标准合规性。

---

我期望(或者至少希望)实现如下:

• 在编译时发出警告，如果 atomic_ref 用于 alignof 小于 required_alignment 的任何对象。您可能知道某个 T *p 恰好是 8 字节对齐的，即使 alignof(T) 只有 1 或 4，所以这不应该是一个错误。

  某种消除警告的本地方法是一件好事。 (替代方案:使用 GNU C x = __builtin_assume_aligned(x, 16) 之类的东西来保证与编译器的对齐)

  如果一个对象在编译时明确已知未对齐，至少会发出警告，例如其对齐方式已知的结构体的子成员，或声明可见但不包含 alignas 的全局变量。通过可能未对齐的指针进行访问的警告会产生更大的噪音，应单独禁用。

• 超慢 Debug模式:运行时检查对齐，对未对齐原子性的特定对象发出警告或中止。 (例如 gcc -fsanitize=undefined ，或者 MSVC 的 Debug模式已经添加了 std::vector::operator[] 边界检查之类的内容。我认为 GCC 的 UBSan 比 MSVC Debug模式做了更多的检查，例如签名溢出；我认为 MSVC Debug模式介于 gcc -O0 和 gcc -O0 -fsanitize=undefined 之间。)

• “发布”模式:零检查，仅发出asm，其正确性取决于正在对齐的对象。 (还有不带 UBSan 的 gcc -O0，它允许一致的调试，但不添加额外的检查。)

• 没有人希望在编译时或运行时静默回退到互斥体。这种操作模式基本上就存在，因此 ISO C++ 可以要求该功能在所有地方都得到支持，而不会使其无法在某些目标上实现。

  与关键部分的手动细粒度锁定(在为其设计的数据结构上同时执行一些相关的原子操作)相比，回退到锁定通常是非常次优的。人们使用 atomic<T> (以及即将推出的 atomic_ref<T> )来提高性能，而大部分性能都会被锁定破坏。尤其是读取端的可扩展性。

脚注 1:IIRC，alignof() 仅指定用于类型，而不是对象，但在 GNU C++ 中它也适用于对象。我使用它作为编译器内部知识的简写，即某个对象使用 alignas() 来过度对齐它。