std::memory_order_relaxed 相对于同一原子变量的原子性

std::memory_order_relaxed atomicity with respect to the same atomic variable

本文关键字：变量 原子性 相对于 memory order relaxed std      更新时间：2023-10-16

关于内存顺序的cpp首选项文档说

宽松内存排序的典型用途是递增计数器，例如 std：：shared_ptr 的引用计数器，因为这只需要原子性，而不需要排序或同步(请注意，递减shared_ptr计数器需要与析构函数进行获取-发布同步)

这是否意味着宽松的内存排序实际上不会导致相对于同一变量的原子性？ 而只是导致与其他放松的内存负载和/或compare_exchange的最终一致性？ 使用std::memory_order_seq_cst将是与std::memory_order_relaxed配对时看到一致结果的唯一方法？

我假设std::memory_order_relaxed对于同一变量仍然是原子的，但不会提供关于其他数据的加载和存储的任何其他约束。

您问了几件事，但我将重点介绍典型shared_ptr实现使用的排序约束，因为我认为这涵盖了您问题的关键部分。

原子操作对于它所应用的变量(或 POD)始终是原子的;对单个变量的修改将按一致的顺序对所有线程可见.
您的问题中描述了宽松的原子操作工作方式：

std::memory_order_relaxed对于同一变量仍然是原子的，但不提供有关其他数据的加载和存储的任何其他约束

以下是 2 个典型的场景，其中可以省略原子操作的排序约束(即通过使用std::memory_order_relaxed)：

内存

  1. 排序不是必需的，因为没有对其他操作的依赖，或者正如注释者所说，(..)不是涉及其他内存位置的不变的一部分。

    一个常见的例子是原子计数器，它按多个线程递增，以跟踪特定事件发生的次数。 如果计数器表示不依赖于其他操作的值，则可以放宽增量操作(fetch_add).
    我发现cppreference给出的示例不是很有说服力，因为shared_ptr引用计数确实具有依赖关系;即，一旦内存的值变为零，内存就会被删除。 一个更好的例子是 Web 服务器仅出于报告目的跟踪传入请求的数量。

  2. 内存排序是必需的，但不需要使用排序约束，因为所需的同步已经通过 (IMO 这更好地解释了为什么shared_ptr的引用计数增量可以放宽，请参阅下面的示例).
    shared_ptrcopy/move 构造函数只能在具有(引用)复制/移动实例的同步视图时调用(否则它将是未定义的行为) 因此，无需额外订购。

下面的示例说明了shared_ptr实现通常如何使用内存排序来修改其引用计数。假设所有线程并行运行后sp_main已发布(shared_ptr引用计数为 10)。

int main()
{
std::vector<std::thread> v;
auto sp_main = std::make_shared<int>(0);
for (int i = 1; i <= 10; ++i)
{
// sp_main is passed by value
v.push_back(thread{thread_func, sp_main, i});
}
sp_main.reset();
for (auto &t : v)  t.join();
}
void thread_func(std::shared_ptr<int> sp, int n)
{
// 10 threads are created
if (n == 7)
{
// Only thread #7 modifies the integer
*sp = 42;
}
// The only thead with a synchronized view of the managed integer is #7
// All other threads cannot read/write access the integer without causing a race
// 'sp' going out of scope -> destructor called
}

线程创建保证了make_shared(在main中)和sp的复制/移动构造函数(在每个线程内)之间的(线程间)发生之前的关系。 因此，shared_ptr的构造函数具有内存的同步视图，并且可以安全地递增ref_count而无需额外的排序：

ctrlblk->ref_count.fetch_add(1, std::memory_order_relaxed);

对于销毁部分，由于只有线程#7写入共享整数，因此不允许其他 9 个线程访问相同的内存位置而不会引起争用。 这会产生一个问题，因为所有线程几乎同时被破坏(假设之前已经调用了main中的reset) 并且只有一个线程将删除共享整数(从 1 递减ref_count到 0 的线程).
最后一个线程在删除整数之前必须具有同步内存视图，但由于 10 个线程中有 9 个没有同步视图，因此需要额外的排序。

析构函数可能包含以下内容：

if (ctrlblk->ref_count.fetch_sub(1, std::memory_order_acq_rel) == 1)
{
// delete managed memory
}

原子ref_count具有单个修改顺序，因此所有原子修饰都按某种顺序发生。 假设对ref_count执行最后 3 个递减的线程(在此示例中)是线程#7(3 → 2)、#5(2 → 1) 和#3(1 → 0)。 线程执行的递减#7和#5在修改顺序上都早于#3.
执行的递减，发布顺序变为：

#7(商店发布)→#5(读取-修改-写入，无需订购)→#3(负载获取)

最终结果是线程#7执行的释放操作与#3执行的获取操作同步，并且整数修改(通过#7)保证具有 发生在整数销毁之前(按#3)。

从技术上讲，只有访问了托管内存位置的线程才必须执行发布操作，但由于库实现者不知道线程操作， 所有线程在销毁时都执行释放操作。

对于共享内存的最终销毁，从技术上讲，只有最后一个线程需要执行获取操作，因此shared_ptr库实现者可以通过设置独立围栏进行优化 仅由最后一个线程调用。

if (ctrlblk->ref_count.fetch_sub(1, std::memory_order_release) == 1)
{
std::atomic_thread_fence(std::memory_order_acquire);
// delete managed memory
}
相关文章：