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

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)

有一天,我将生活在理论中,因为理论上每件事情都很顺利 --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的特性:"原子访问是一种可观察的行为".根据标准,它不是(标准中关于这个事实的明确的例子说明).这是关于SO的反复出现的问题.

因此,您的代码在理论上确实是最佳代码,并且它是悲观的,因为编译器优化代码就好像原子也是挥发性的.

解决方法可能是用Kieth在评论中提出的atomic_thread_fence来替换负载.我不是硬件专家,但我想这样的围栏可能会导致更多的内存"同步"而不是必要的(或者至少在理论上;)).

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

单个对象的最后一个shared_ptr必须调用该对象的析构函数,而不会导致数据争用.析构函数可以访问对象的值,因此析构函数调用必须在指向对象的指针"失效"之后发生.

所以delete p;必须"发生在"所有其他共享同一个尖头对象的共享指针的析构函数调用之后.

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

[intro.races]/9:

评估A线程在评估B之前发生,如果:

• 与B同步,或[...]

• 任何与"之前排序"的组合,它是一个传递规则.

[intro.races]/10:

评估A发生在评估B之前(或等效地,B发生在A之后),如果:

• A在B之前排序,或

• 线程发生在B之前.

因此,fetch_sub在之前delete p和之前排序的之间必须存在"同步"关系fetch_sub.

根据[atomics.order]/2:

对原子对象M执行释放操作的原子操作A与对M执行获取操作的原子操作B同步,并且从由A开头的释放序列中的任何副作用获取其值.

因此delete p必须在获取操作之后对其进行排序,该操作加载在所有其他的释放序列中的值fetch_sub.

根据[expr.races]/5,最后一个fetch_sub(在cnt的修改顺序中)将属于所有其他版本的释放序列,fetch_sub因为a fetch_sub是读取 - 修改 - 写入操作,原样是fetch_add(假设没有其他操作发生在cnt).

因此delete p将在所有其他fetch_sub之后发生,并且只有在delete p调用之前才会产生"同步".确切地说,不是必要的.