AFAIK C++ 原子(<atomic>)系列提供 3 个好处:

• 原始指令不可分割性(无脏读)，
• 内存排序(CPU 和编译器)和
• 跨线程可见性/更改传播。

我不确定第三个项目符号，因此请看下面的示例。

#include <atomic>

std::atomic_bool a_flag = ATOMIC_VAR_INIT(false);
struct Data {
    int x;
    long long y;
    char const* z;
} data;

void thread0()
{
    // due to "release" the data will be written to memory
    // exactly in the following order: x -> y -> z
    data.x = 1;
    data.y = 100;
    data.z = "foo";
    // there can be an arbitrary delay between the write 
    // to any of the members and it's visibility in other 
    // threads (which don't synchronize explicitly)

    // atomic_bool guarantees that the write to the "a_flag"
    // will be clean, thus no other thread will ever read some
    // strange mixture of 4bit + 4bits
    a_flag.store(true, std::memory_order_release);
}

void thread1()
{
    while (a_flag.load(std::memory_order_acquire) == false) {};
    // "acquire" on a "released" atomic guarantees that all the writes from 
    // thread0 (thus data members modification) will be visible here
}

void thread2()
{
    while (data.y != 100) {};
    // not "acquiring" the "a_flag" doesn't guarantee that will see all the 
    // memory writes, but when I see the z == 100 I know I can assume that 
    // prior writes have been done due to "release ordering" => assert(x == 1)
}

int main()
{
    thread0(); // concurrently
    thread1(); // concurrently
    thread2(); // concurrently

    // join

    return 0;
}

首先，请在代码中验证我的假设(尤其是 thread2 )。

其次，我的问题是:

1. 如何a_flag写入传播到其他核心？

2. std::atomic同步 a_flag在与其他核心缓存(使用 MESI 或其他任何东西)的写入器缓存中，或者传播是自动的？

3. 假设在特定机器上对标志的写入是原子的(想想 x86 上的 int_32)并且我们没有任何私有(private)内存可以同步(我们只有一个标志)我们是否需要使用原子？

4. 考虑到最流行的 CPU 架构(x86、x64、ARM v.whatever、IA-64)，跨核可见性(我现在不考虑重新排序)是自动的(但可能会延迟)，或者您需要发出特定命令来传播任何数据？

最佳答案

1. 核心本身并不重要。问题是“所有核心如何最终看到相同的内存更新”，这是您的硬件为您做的事情(例如缓存一致性协议(protocol))。内存只有一 block ，所以主要关注的是缓存，这是硬件的私有(private)关注点。

2. 这个问题似乎不清楚。重要的是由 a_flag 的加载和存储形成的获取-释放对，它是一个同步点并导致 thread0 和 thread1 以特定顺序出现(即 thread0 中的所有内容在存储之前 happens-before thread1 中循环之后的所有内容)。

3. 是的，否则你不会有同步点。

4. 您不需要 C++ 中的任何“命令”。 C++ 甚至不知道它运行在任何特定类型的 CPU 上这一事实。凭借足够的想象力，您或许可以在魔方上运行 C++ 程序。 C++ 编译器 选择必要的指令来实现 C++ 内存模型所描述的同步行为，并且在 x86 上涉及发出指令锁前缀和内存栅栏，并且不会过多地重新排序指令。由于 x86 具有强有序内存模型，因此与没有原子性的天真、不正确的代码相比，上述代码应该产生最少的额外代码。

5. 在代码中包含您的 thread2 会使整个程序出现未定义的行为。

只是为了好玩，并且为了表明弄清楚自己正在发生的事情是有启发性的，我将代码编译成三种变体。 (我添加了一个 glbbal int x 并在 thread1 中添加了 x = data.y;)。

获取/释放:(您的代码)

thread0:
    mov DWORD PTR data, 1
    mov DWORD PTR data+4, 100
    mov DWORD PTR data+8, 0
    mov DWORD PTR data+12, OFFSET FLAT:.LC0
    mov BYTE PTR a_flag, 1
    ret

thread1:
.L14:
    movzx   eax, BYTE PTR a_flag
    test    al, al
    je  .L14
    mov eax, DWORD PTR data+4
    mov DWORD PTR x, eax
    ret

顺序一致:(去除显式排序)

thread0:
    mov eax, 1
    mov DWORD PTR data, 1
    mov DWORD PTR data+4, 100
    mov DWORD PTR data+8, 0
    mov DWORD PTR data+12, OFFSET FLAT:.LC0
    xchg    al, BYTE PTR a_flag
    ret

thread1:
.L14:
    movzx   eax, BYTE PTR a_flag
    test    al, al
    je  .L14
    mov eax, DWORD PTR data+4
    mov DWORD PTR x, eax
    ret

“朴素”:(仅使用 bool)

thread0:
    mov DWORD PTR data, 1
    mov DWORD PTR data+4, 100
    mov DWORD PTR data+8, 0
    mov DWORD PTR data+12, OFFSET FLAT:.LC0
    mov BYTE PTR a_flag, 1
    ret

thread1:
    cmp BYTE PTR a_flag, 0
    jne .L3
.L4:
    jmp .L4
.L3:
    mov eax, DWORD PTR data+4
    mov DWORD PTR x, eax
    ret

如您所见，两者没有太大区别。 “不正确”版本实际上看起来大部分是正确的，除了缺少加载(它使用 cmp 和内存操作数)。顺序一致的版本将其昂贵隐藏在 xcgh 指令中，该指令具有隐式锁定前缀并且似乎不需要任何显式栅栏。

关于C++ 原子和跨线程可见性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19421192/