共享指针析构函数中的内存顺序

Question

我试图找出共享指针析构函数最轻松（和正确）的内存顺序。我现在的想法如下：

~shared_ptr() {
   if (p) {
     if (p->cnt.fetch_sub(1, std::memory_order_release) == 1) {
       p->cnt.load(std::memory_order_acquire);
       delete p;
     }
   }
 }

基本上，我认为所有之前的fetch_sub() 都应该发生在delete p; 之前，并且通过p->cnt.load(std::memory_order_acquire);，我构建了一个发布序列来确保这一点。

我是 C++ 内存模型的新手，不太自信。我上面的推理是否正确，我指定的记忆顺序正确且最轻松？

Answer 1

在理论上，您可能拥有最高效的代码，因为没有多余的同步。

但在实践中，几乎没有 CPU 提供可以完美映射到获取/释放内存顺序的指令（也许未来 ARMv8.3-A 会）。所以你必须检查每个目标生成的代码。

例如在 x86_64 上，fetch_sub(std::memory_order_acq_rel) 和 fetch_sub(std::memory_order_release) 将产生完全相同的指令。

因此，虽然您的代码在理论上看起来是最优的，但在实践中，您得到的代码不如您选择更简单的方法：

std::atomic<int> cnt;
int* p;
void optimal_in_therory() {
     if (cnt.fetch_sub(1, std::memory_order_release) == 1) {
       cnt.load(std::memory_order_acquire);
       delete p;
   }
}
void optimal_in_practice_on_x86_64() {
     if (cnt.fetch_sub(1, std::memory_order_acq_rel) == 1) {
       delete p;
   }
}

组装：

optimal_in_therory():
  lock sub DWORD PTR cnt[rip], 1
  je .L4
  rep ret
.L4:
  mov eax, DWORD PTR cnt[rip]  ;Unnecessary extra load
  mov rdi, QWORD PTR p[rip]
  mov esi, 4
  jmp operator delete(void*, unsigned long)
optimal_in_practice_on_x86_64():
  lock sub DWORD PTR cnt[rip], 1
  je .L7
  rep ret
.L7:
  mov rdi, QWORD PTR p[rip]
  mov esi, 4
  jmp operator delete(void*, unsigned long)

有一天我会生活在 Theory 中，因为在 Theory 中，每件事都很顺利 -Pierre Desproges

---

为什么编译器会保留这个额外的负载？

根据标准，优化器可以省略在非易失性原子上执行的冗余负载。例如，如果您在代码中添加了三个额外负载：

cnt.load(std::memory_order_acquire);
cnt.load(std::memory_order_acquire);
cnt.load(std::memory_order_acquire);

使用 GCC 或 Clang，三个负载将出现在程序集中：

mov eax, DWORD PTR cnt[rip]
mov eax, DWORD PTR cnt[rip]
mov eax, DWORD PTR cnt[rip]

这是一种非常糟糕的悲观情绪。 我的观点是因为“易失性”和“原子性”之间的历史混淆，它保持原样。虽然几乎所有程序员都知道 volatile 不具有原子变量的属性，但许多代码仍然以原子具有 volatile 属性的想法编写：“原子访问是一种可观察的行为”。根据标准，它不是（明确的example note about this fact in the standard）。这是关于 SO 的一个反复出现的问题。

所以你的代码在理论上确实是最优的代码，它是悲观的，因为编译器优化代码，好像原子也是易失性的。

解决方法可能是用 Kieth 在其评论中提出的 atomic_thread_fence 替换负载。我不是硬件专家，但我认为这样的栅栏可能会导致更多的内存“同步”而不是必要的（或至少在理论上 ;)）。

为什么我认为您的代码在理论上是最优的？

单个对象的最后一个 shared_ptr 必须调用该对象的析构函数，而不会引起数据竞争。析构函数可以访问对象的值，所以析构函数调用必须发生在指向对象的指针“失效”之后。

所以delete p; 必须“发生在”所有其他共享同一个指向对象的共享指针的析构函数调用之后。

在标准发生之前由以下段落定义：

[intro.races]/9：

如果满足以下条件，则评估 A 线程间发生在评估 B 之前：

• A 与 B 同步，或者 [...]

• 与“sequenced before”的任何组合，它是一个传递规则。

[intro.races]/10：

如果：

• A 在 B 之前排序，或者

• 线程间发生在 B 之前。

因此，在delete p 之前排序的fetch_sub 与另一个fetch_sub 之间必须存在“同步”关系。

根据[atomics.order]/2：

对原子对象 M 执行释放操作的原子操作 A 与对 M 执行获取操作的原子操作 B 同步，并从以 A 为首的释放序列中的任何副作用获取其值。

所以delete p 必须在获取操作之后排序，该操作加载一个值，该值位于所有其他fetch_sub 的释放序列中。

根据[expr.races]/5，最后一个fetch_sub（按cnt的修改顺序）将属于所有其他版本fetch_sub的发布顺序，因为fetch_sub是一个read-modify-write 操作，就像fetch_add 一样（假设cnt 上没有发生其他操作）。

所以delete p 将在所有其他 fetch_sub 之后发生，并且只有在调用 delete p 之前才会产生“同步”。正好不是必要的。