std::memory_order_relaxed 同一个原子变量的原子性

Question

关于内存顺序的 cppreference 文档说

Typical use for relaxed memory ordering is incrementing counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing the shared_ptr counters requires acquire-release synchronization with the destructor)

这是否意味着宽松的内存排序实际上不会导致同一变量的原子性？而只是导致相对于其他宽松内存负载的最终一致性 and/or compare_exchanges？使用 std::memory_order_seq_cst 将是与 std::memory_order_relaxed?

配对时看到一致结果的唯一方法

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

Answer 1

您问了一些问题，但我将重点关注典型 shared_ptr 实现所使用的排序约束，因为我认为这涵盖了您问题的关键部分。

一个原子操作总是相对于它所应用的变量（或 POD）是原子的；对单个变量的修改将以一致的顺序对所有线程可见。
您的问题中描述了宽松原子操作的工作方式：

std::memory_order_relaxed is still atomic with respect to the same variable but does not provide any other constraints about loads and stores with respect to other data

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

内存排序不是必需的，因为不依赖于其他操作，或者正如评论者所说，(..) 不是涉及其他内存位置的不变量的一部分。

一个常见的例子是原子计数器，由多个线程递增以跟踪特定事件发生的次数。如果计数器表示的值不依赖于其他操作，则可以放宽增量操作 (fetch_add)。
我发现 cppreference 给出的示例不太令人信服，因为 shared_ptr 引用计数确实具有依赖性；即一旦其值变为零，内存就会被删除。一个更好的例子是 Web 服务器仅出于报告目的跟踪传入请求的数量。
内存排序是必要的，但是不需要使用排序约束，因为要求的同步已经通过（IMO 这更好地解释了为什么可以放宽 shared_ptr 的引用计数增量，请参见下面的示例）。
shared_ptr copy/move 构造函数只能在它具有 copied/moved-from 实例的（引用）同步视图时调用（否则它将是未定义的行为）因此，无需额外订购。

以下示例说明了 shared_ptr 实现通常如何使用内存排序来修改其引用计数。假设所有线程运行并行 after 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 的 copy/move 构造函数（在每个线）。因此，shared_ptr 的构造函数具有内存的同步视图，并且可以安全地递增 ref_count 而无需额外的排序：

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

对于销毁部分，由于只有线程 #7 写入共享整数，因此不允许其他 9 个线程在不引起竞争的情况下访问同一内存位置。这会产生一个问题，因为所有线程几乎同时被破坏（假设 main 中的 reset 已被更早调用）并且只有一个线程将删除共享整数（一个递减 ref_count 从 1 到 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 (store release) → #5 (read-modify-write, no ordering required) → #3 (load acquire)

最终结果是线程#7执行的release操作和#3执行的acquire操作同步了，整数修改（#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
}

std::memory_order_relaxed 同一个原子变量的原子性

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

c++

multithreading

atomic

memory-barriers

stdatomic