共享指针析构函数中的内存顺序
Memory order in shared pointer destructor
我正在尝试为共享指针析构函数找出最宽松(和正确)的内存顺序。目前我的想法如下:
~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提供的指令可以完美映射到acquire/release内存顺序(也许将来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
为什么编译器保留这个extra-load?
根据标准,允许优化器消除对非易失性原子执行的冗余负载。例如,如果在您的代码中添加了三个 extra-loads:
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]
这是一个非常糟糕的悲观主义。 我的意见 保留它 as-is 是因为历史上混淆了“波动性”和“原子性”。虽然几乎所有的程序员都知道 volatile 不具有原子变量的属性,但许多代码编写时仍然认为原子具有 volatile 的属性:“原子访问是一种可观察的行为”。根据标准,它不是(明确的 example note about this fact in the standard)。这是关于 SO 的一个反复出现的问题。
所以你的代码实际上是理论上最优的代码,它是悲观的,因为编译器优化代码,就好像原子也是易变的。
解决方法是按照 Kieth 在其评论中提出的 atomic_thread_fence 替换负载。我不是硬件专家,但我想这样的围栏可能会导致比必要的(或至少在理论上 ;) 更多的内存“同步”。
为什么我认为你的代码理论上是最优的?
单个对象的最后一个 shared_ptr 必须调用该对象的析构函数,而不会导致数据竞争。析构函数可以访问对象的值,因此析构函数调用必须发生在指向对象的指针“失效”之后。
因此 delete p;
必须“发生在”共享同一个指向对象的所有其他共享指针的析构函数调用之后。
在标准之前发生是由以下段落定义的:
[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
.
之间必须存在“同步”关系
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
是 read-modify-write 操作,fetch_add
也是(假设 cnt
上没有其他操作发生)。
所以delete p
会在所有其他fetch_sub之后发生,并且只有在delete p
被调用之前才会产生“同步”。恰恰不超过必要的。
我正在尝试为共享指针析构函数找出最宽松(和正确)的内存顺序。目前我的想法如下:
~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提供的指令可以完美映射到acquire/release内存顺序(也许将来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
为什么编译器保留这个extra-load?
根据标准,允许优化器消除对非易失性原子执行的冗余负载。例如,如果在您的代码中添加了三个 extra-loads:
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]
这是一个非常糟糕的悲观主义。 我的意见 保留它 as-is 是因为历史上混淆了“波动性”和“原子性”。虽然几乎所有的程序员都知道 volatile 不具有原子变量的属性,但许多代码编写时仍然认为原子具有 volatile 的属性:“原子访问是一种可观察的行为”。根据标准,它不是(明确的 example note about this fact in the standard)。这是关于 SO 的一个反复出现的问题。
所以你的代码实际上是理论上最优的代码,它是悲观的,因为编译器优化代码,就好像原子也是易变的。
解决方法是按照 Kieth 在其评论中提出的 atomic_thread_fence 替换负载。我不是硬件专家,但我想这样的围栏可能会导致比必要的(或至少在理论上 ;) 更多的内存“同步”。
为什么我认为你的代码理论上是最优的?
单个对象的最后一个 shared_ptr 必须调用该对象的析构函数,而不会导致数据竞争。析构函数可以访问对象的值,因此析构函数调用必须发生在指向对象的指针“失效”之后。
因此 delete p;
必须“发生在”共享同一个指向对象的所有其他共享指针的析构函数调用之后。
在标准之前发生是由以下段落定义的:
[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
.
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
是 read-modify-write 操作,fetch_add
也是(假设 cnt
上没有其他操作发生)。
所以delete p
会在所有其他fetch_sub之后发生,并且只有在delete p
被调用之前才会产生“同步”。恰恰不超过必要的。