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

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

但是实际上，几乎没有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)

有一天，我将生活在理论中，因为理论上一切都会顺利进行-皮埃尔·德斯普鲁日

---

为何编译器会保留此额外负载？

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

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的特性：“原子访问是一种可观察的行为”。根据标准，它不是（关于此事实的明确示例注释）。这是关于SO的一个反复出现的问题。

因此，从理论上讲，您的代码实际上是最佳代码，并且由于被编译器像原子一样也是易失性的那样对代码进行优化，因此您的代码受到了悲观的评价。

解决方法可能是用Kieth在其注释中建议的atomic_thread_fence替换负载。我不是硬件专家，但我认为这样的隔离可能会导致不必要的内存“同步”（或者至少在理论上是这样）。

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

单个对象的最后一个shared_ptr必须调用该对象的析构函数，而本身不会引起数据争用。析构函数可以访问对象的值，因此，在指向对象的指针“无效”之后，必须进行析构函数调用。

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

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

[介绍种族] / 9：

在以下情况下，评估A线程间发生在评估B之前：

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

• 与“先后顺序”的任何组合，这是一个传递规则。

[介绍种族] / 10：

在以下情况下，评估A发生在评估B之前（或等效地，B发生在A之后）：

• A在B之前排序，或者

• 线程间发生在B之前。

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

根据[atomics.order] / 2：

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

因此delete p必须在获取操作之后进行排序，该操作将加载所有其他操作的释放顺序中的值fetch_sub。

根据[expr.races] / 5的最后一个fetch_sub（在CNT的修改顺序）将属于其他版的所有版本序列fetch_sub，因为fetch_sub是读-修改-写操作，如fetch_add（假设没有其他操作发生在cnt）。

因此，delete p将在所有其他fetch_sub之后发生，并且仅在delete p被称为“同步”之前才会产生。完全没有必要的东西。