我试图找出共享指针析构函数最放松(和正确)的内存顺序。我现在想到的是如下:
~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 ++内存模型的新手,并不太自信。我的上述推理是否正确,我指定的内存顺序是否正确且最轻松?
从理论上讲,您可能拥有最有效的代码,因为没有必要的同步。
但在实践中,几乎没有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的特性:“原子访问是一种可观察的行为”。根据标准,它不是(明确的example note about this fact in the standard)。这是关于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
之间必须存在“同步”关系。
对原子对象M执行释放操作的原子操作A与对M执行获取操作的原子操作B同步,并且从由A开头的释放序列中的任何副作用获取其值。
所以delete p
必须在获取操作之后进行排序,该操作加载所有其他fetch_sub
的释放序列中的值。
根据[expr.races]/5,最后的fetch_sub
(在cnt的修改顺序中)将属于所有其他版本fetch_sub
的释放序列,因为fetch_sub
是读取 - 修改 - 写入操作,fetch_add
(假设没有其他操作发生在cnt
) 。
所以delete p
将在所有其他fetch_sub之后发生,并且只有在调用delete p
之前才会产生“同步”。确切地说,不是必要的。