我正在尝试为共享指针析构函数找出最宽松(和正确)的内存顺序。目前我的想法如下:
~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
为什么编译器要保留这个额外的负载?
根据标准,允许优化器消除对非 volatile 原子执行的冗余负载。例如,如果在您的代码中添加了三个额外负载:
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;
必须“发生在”共享同一个指向对象的所有其他共享指针的析构函数调用之后。
在标准中happens before 由以下段落定义:
[intro.races]/9:
An evaluation A inter-thread happens before an evaluation B if:
- A synchronizes with B, or [...]
- 与“sequenced before”的任意组合都是传递规则。
[intro.races]/10:
An evaluation A happens before an evaluation B (or, equivalently, B happens after A) if:
A is sequenced before B, or
A inter-thread happens before B.
因此在 delete p
之前排序的 fetch_sub
和另一个 fetch_sub
之间必须存在“同步”关系。
根据 [atomics.order]/2 :
An atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and takes its value from any side effect in the release sequence headed by A.
因此 delete p
必须在获取操作之后排序,该操作加载一个值,该值在所有其他 fetch_sub
的释放序列中。
根据 [expr.races]/5最后一个 fetch_sub
(在 cnt 的修改顺序中)将属于所有其他版本 fetch_sub
的发布序列,因为 fetch_sub
是 < em>read-modify-write 操作,fetch_add
也是(假设cnt
上没有其他操作发生)。
所以 delete p
将在所有其他 fetch_sub 之后发生,并且只有在调用 delete p
之前才会产生“同步”。恰好不要超过必要的数量。
关于c++ - 共享指针析构函数中的内存顺序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49112732/