不能像 store 一样在 x86 上放宽原子 fetch_add 重新排序，稍后加载？

如何解决不能像 store 一样在 x86 上放宽原子 fetch_add 重新排序，稍后加载？

这个程序有时会打印 00，但是如果我注释掉 a.store 和 b.store 并取消注释 a.fetch_add 和 b.fetch_add，它们会做完全相同的事情，即都设置 a=1,b=1 的值，我从来没有得到00。（在 x86-64 Intel i3 上测试，使用 g++ -O2）

我是不是遗漏了什么，或者按照标准“00”永远不会出现？

这是带有普通商店的版本，可以打印00。

// g++ -O2 -pthread axbx.cpp  ; while [ true ]; do ./a.out  | grep "00" ; done
#include<cstdio>
#include<thread>
#include<atomic>
using namespace std;
atomic<int> a,b;
int reta,retb;

void foo(){
        //a.fetch_add(1,memory_order_relaxed);
        a.store(1,memory_order_relaxed);
        retb=b.load(memory_order_relaxed);
}

void bar(){
        //b.fetch_add(1,memory_order_relaxed);
        b.store(1,memory_order_relaxed);
        reta=a.load(memory_order_relaxed);
}

int main(){
        thread t[2]{ thread(foo),thread(bar) };
        t[0].join(); t[1].join();
        printf("%d%d\n",reta,retb);
        return 0;
}

下面从不打印 00

// g++ -O2 -pthread axbx.cpp  ; while [ true ]; do ./a.out  | grep "00" ; done
#include<cstdio>
#include<thread>
#include<atomic>
using namespace std;
atomic<int> a,retb;

void foo(){
        a.fetch_add(1,memory_order_relaxed);
        //a.store(1,memory_order_relaxed);
        retb=b.load(memory_order_relaxed);
}

void bar(){
        b.fetch_add(1,memory_order_relaxed);
        //b.store(1,retb);
        return 0;
}

也看看这个Multithreading atomics a b printing 00 for memory_order_relaxed

解决方法

标准允许 00，但你永远不会在 x86 上得到它（没有编译时重新排序）。在 x86 involves a lock prefix 上实现原子 RMW 的唯一方法，这是一个“完全屏障”，对于 seq_cst 来说已经足够强大了。

在 C++ 术语中，在为 x86 编译时，原子 RMW 被有效地提升为 seq_cst。（只有在确定了可能的编译时排序之后——例如，非原子加载/存储可以通过宽松的 fetch_add 重新排序/组合，其他宽松的操作也是如此，以及使用获取或释放操作的单向重新排序。虽然编译器较少自 they don't combine them 起可能会相互重新排序原子操作，这样做是编译时重新排序的 main reasons 之一。）

事实上，大多数编译器通过使用 a.store(1,mo_seq_cst)（它有一个隐含的 xchg 前缀）来实现 lock，因为它比 mov + mfence 在现代 CPU，将 0 变成 1 并将 lock add 作为对每个对象的唯一写入是完全相同的。有趣的事实：只需存储和加载，您的代码将编译为与 https://preshing.com/20120515/memory-reordering-caught-in-the-act/ 相同的 asm，因此此处的讨论适用。

ISO C++ 允许整个松散的 RMW 以松散的负载重新排序，但普通编译器不会在编译时无缘无故地这样做。（DeathStation 9000 C++ 实现可以/将会）。因此，您终于找到了在不同的 ISA 上进行测试很有用的案例。原子 RMW（或其中的一部分）在运行时重新排序的方式在很大程度上取决于 ISA。

需要重试循环来实现 fetch_add 的 LL/SC 机器（例如 ARM 或 AArch64 before ARMv8.1）可能能够真正实现可在运行时重新排序的宽松 RMW，因为任何比放松就需要障碍。（或者获取/发布指令的版本，例如 AArch64 ldaxr / stlxr vs. ldxr/stxr）。因此，如果relaxed 与acq 和/或rel 之间存在asm 差异（有时seq_cst 也不同），则可能需要差异并防止某些运行时重新排序。

在 AArch64 上，即使是单指令原子操作也能真正放松；我没有调查过。大多数弱序 ISA 传统上都使用 LL/SC 原子，所以我可能只是将它们混为一谈。

在 LL/SC 机器中，LL/SC RMW 的存储端甚至可以与以后的负载分开重新排序，除非它们都是 seq_cst。 For purposes of ordering,is atomic read-modify-write one operation or two?

要真正看到 00，两个加载都必须在 RMW 的存储部分在另一个线程中可见之前发生。是的，我认为 LL/SC 机器中的硬件重新排序机制与重新排序普通商店非常相似。

这个问题的关键是要意识到 relaxed memory ordering 不能保证线程之间的同步：

标记为memory_order_relaxed的原子操作不是同步操作；它们不在并发内存访问之间强加顺序。它们只保证原子性和修改顺序的一致性。

因此在第一个代码中，可能会发生不同的情况。例如：

先执行 foo() 的线程中的代码，然后执行 bar() 的线程：retb 为 0，reta 为 1，因此您将得到 10。
先执行 bar() 的线程中的代码，然后执行 foo() 的线程：reta 为 0，retb 为 1，因此您将得到 01。
foo() 和 bar() 的线程中的代码同时逐条指令执行。那么 reta 和 retb 都是 1，你会得到 11。
宽松的内存排序也允许不同步的情况：两个线程更新它们的原子并查看它们的当前原子值，但看到另一个线程的未同步值（即原子更改之前的值）。因此，您可以在 0 处 reta 和 retb 获得 00。

第二个代码遇到了同样的问题，因为它是宽松的排序，并且用于设置 reta 和 retb 的访问是对在另一个线程中修改的原子的只读访问。您可以拥有所有四种可能性。

如果你想确保同步按预期发生，你需要确保所有原子操作之间的全局顺序，因此使用memory_order_seq_cst。这将排除 00，但仍保留所有其他组合。

（注意：我之前建议使用 memory_order_acquire 确实是不够的，因为它仍然保证在不同原子操作的线程之间没有顺序，正如 Peter 在评论中解释的那样）

在这两种情况下我都得到“10”。第一个线程将始终运行得更快并且a == 1！但是如果你向 foo()

添加额外的操作

#include<cstdio>
#include<thread>
#include<atomic>
using namespace std;
atomic<int> a,b;
int reta,retb;

void foo(){

    int i=0;
    while(i < 10000000)
        i++;

    a.fetch_add(1,memory_order_relaxed);
    //a.store(1,memory_order_relaxed);
    retb=b.load(memory_order_relaxed);
}

void bar(){
    b.fetch_add(1,memory_order_relaxed);
    //b.store(1,memory_order_relaxed);
    reta=a.load(memory_order_relaxed);
}

int main(){
    thread t[2]{ thread(foo),thread(bar) };
    t[0].join(); t[1].join();
    printf("%d%d\n",reta,retb);
    return 0;
}

您将收到“01”！

不能像 store 一样在 x86 上放宽原子 fetch_add 重新排序，稍后加载？

如何解决不能像 store 一样在 x86 上放宽原子 fetch_add 重新排序，稍后加载？

解决方法

相关推荐