假设有以下代码示例，它旨在等待另一个线程将42存储在共享变量shared中，而不需要锁定并且不需要等待线程终止。为什么需要或建议使用volatile T或std::atomic<T>来保证并发正确性？
#include <atomic>
#include <cassert>
#include <cstdint>
#include <thread>
int main()
{
int64_t shared = 0;
std::thread thread([&shared]() {
shared = 42;
});
while (shared != 42) {
}
assert(shared == 42);
thread.join();
return 0;
}
使用 GCC 4.8.5 和默认选项，示例能够正常工作。
这个测试似乎表明样本是正确的，但实际上并不是。类似的代码可能很容易地进入生产环境，并且甚至可能运行多年而没有问题。
我们可以使用-O3编译样本。现在，该样本无限期挂起。（默认值为-O0，即无优化/调试一致性，有点类似于使每个变量volatile，这就是测试未能揭示代码不安全的原因。）
要找到根本原因，我们必须检查生成的汇编代码。首先，GCC 4.8.5 -O0基于x86_64汇编对应于未经优化的工作二进制文件：
// Thread B:
// shared = 42;
movq -8(%rbp), %rax
movq (%rax), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
.L11:
movq -32(%rbp), %rax # Check shared every iteration
cmpq $42, %rax
jne .L11
线程B在shared中执行一个简单的存储值42。
线程A在每个循环迭代中读取shared，直到比较指示相等。
现在，我们将其与-O3结果进行比较：
// Thread B:
// shared = 42;
movq 8(%rdi), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
cmpq $42, (%rsp) # check shared once
je .L87 # and skip the infinite loop or not
.L88:
jmp .L88 # infinite loop
.L87:
-O3关联，用一个单一比较替换了循环，并且如果不相等，就是一个无限循环来匹配期望行为。在GCC 10.2中，循环被优化掉了。（与C不同，没有副作用或易失性访问的无限循环在C++中是未定义的行为。）shared 在线程A中不能更改——循环等同于死代码。（或者换句话说，竞争数据是未定义的行为，优化器允许假设程序不会遇到未定义的行为。如果你正在读取非原子变量，那么这必须意味着没有人写它。这就允许编译器将负载提升出循环，并类似地下沉存储，这些对于非共享变量的正常情况非常有价值的优化。）shared。完成这个任务的一种方法可能是使用volatile。虽然volatile的实际含义因编译器而异，并且保证是编译器特定的，但普遍的共识是volatile防止编译器在寄存器缓存方面优化易失性访问。这对于与硬件交互的低级代码至关重要，并且在并发编程中有其存在之处，尽管随着引入std::atomic而呈下降趋势。volatile int64_t shared，生成的指令如下： // Thread B:
// shared = 42;
movq 24(%rdi), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
.L87:
movq 8(%rsp), %rax
cmpq $42, %rax
jne .L87
shared已更改，尽管没有代码的证据。因此，样例现在可以使用-O3。volatile可以解决问题，为什么还需要std::atomic？对于无锁代码相关的两个方面，使std::atomic成为必要：内存操作的原子性和内存顺序。-O3 -m32（32位版本）用于volatile int64_t shared： // Thread B:
// shared = 42;
movl 4(%esp), %eax
movl 12(%eax), %eax
movl $42, (%eax)
movl $0, 4(%eax)
// Thread A:
// while (shared != 42) {
// }
.L88: # do {
movl 40(%esp), %eax
movl 44(%esp), %edx
xorl $42, %eax
movl %eax, %ecx
orl %edx, %ecx
jne .L88 # } while(shared ^ 42 != 0);
#include <atomic>
#include <cassert>
#include <cstdint>
#include <thread>
int main()
{
std::atomic<int64_t> shared;
std::thread thread([&shared]() {
shared.store(42, std::memory_order_relaxed);
});
while (shared.load(std::memory_order_relaxed) != 42) {
}
assert(shared.load(std::memory_order_relaxed) == 42);
thread.join();
return 0;
}
基于 GCC 10.2 生成的32位汇编代码（-O3: https://godbolt.org/z/8sPs55nzT）：
// Thread B:
// shared.store(42, std::memory_order_relaxed);
movl $42, %ecx
xorl %ebx, %ebx
subl $8, %esp
movl 16(%esp), %eax
movl 4(%eax), %eax # function arg: pointer to shared
movl %ecx, (%esp)
movl %ebx, 4(%esp)
movq (%esp), %xmm0 # 8-byte reload
movq %xmm0, (%eax) # 8-byte store to shared
addl $8, %esp
// Thread A:
// while (shared.load(std::memory_order_relaxed) != 42) {
// }
.L9: # do {
movq -16(%ebp), %xmm1 # 8-byte load from shared
movq %xmm1, -32(%ebp) # copy to a dummy temporary
movl -32(%ebp), %edx
movl -28(%ebp), %ecx # and scalar reload
movl %edx, %eax
movl %ecx, %edx
xorl $42, %eax
orl %eax, %edx
jne .L9 # } while(shared.load() ^ 42 != 0);
movq指令（与128位SSE寄存器的底半部分进行交互）。此外，汇编显示尽管已经删除了volatile，但循环仍然保持不变。std::atomic，可以确保：
std::atomic加载和存储不受基于寄存器的缓存的影响std::atomic加载和存储不允许观察到部分值虽然这留下了解释的余地，但像我们的示例中触发的（没有volatile或atomic）跨迭代缓存实现应该使原子存储在合理的时间内对原子加载可见。
std::atomic加载显然是一种违规行为-存储可能永远不会变得可见。当前编译器甚至不会优化同一块内的原子操作，比如同一次迭代中的2个访问。movq的原因。T（例如2个寄存器的大小）的atomic<T>在某些平台上可能不会直接得到支持，此时编译器可以退回使用互斥锁。T可能需要原子RMW操作（如果编译器不简单地退回到锁定），这些操作提供的大小比保证原子的最大有效纯负载/纯存储更大。（例如，在x86-64上，lock cmpxchg16或ARM ldrexd/strexd重试循环）。单指令原子RMW（如x86使用的）在内部涉及缓存行锁定或总线锁定。例如，对于x86的旧版本clang -m32，将使用lock cmpxchg8b而不是movq进行8字节纯负载或纯存储。std::memory_order_relaxed 是什么意思？编译器和 CPU 都可以重新排序内存操作以优化效率。重新排序的主要限制是所有加载和存储必须按照代码给定的顺序执行（程序顺序）。因此，在多线程通信的情况下，必须考虑内存顺序以建立所需的顺序，尽管存在重新排序的尝试。可以为 std::atomic 加载和存储指定所需的内存顺序。std::memory_order_relaxed 不强制执行任何特定顺序。std::memory_order_relaxed 的 std::atomic<T>（除非场景需要特定的内存顺序）而不是 volatile T（当然，T）。此外，尽可能避免自己编写无锁代码以减少代码复杂性并最大化正确性的概率。atomic<T>基本上视为volatile atomic<T>：为什么编译器不合并冗余的std::atomic写入？ 链接了WG21/P0062R1和N4455。 - Peter Cordesmain()看到shared具有值42时，它是未定义的：请参见下面的“优化和重新排序”。即使您的测试没有发现问题：请查看下面的“关于您的测试”！thread可以在while循环之前或thread.join()函数内部的任何位置终止。唯一可以信任的是你的语言所提供的内存模型所保证的内容。
幸运的是，自C++11以来，C++拥有了一个内存模型！
很不幸，该模型并不能提供太多保证。编译器可以生成允许执行任何操作的代码，只要程序的语义在单线程视角下没有改变。这包括省略代码、推迟代码或更改事情发生的顺序。唯一的例外是当您进行保证进展时，或者使用显式共享构造，比如您提到的那些。即使在main()中的while循环执行之前，thread已经终止也是完全可以接受的。因为线程终止是进度的，所以shared可能会出现在main()能够看到它的地方，在while循环之前。在这种情况下，测试似乎是成功的。但是，如果调度有任何不同，测试可能会失败。您永远不应该依赖于调度。
因此，即使您的测试没有发现问题，那也只是个人经验的证明。
正如@horsts excellent answer已经指出的那样，编译器和CPU可以优化您的代码。只要程序语义从单个线程的角度来看没有改变，就允许任何事情发生。
假设你将一个变量分配给一个线程，但在该线程中从未再次读取它（就像你在“thread”中所做的那样）。编译器可以将实际赋值推迟多长时间，因为就目前编译器所能看到的情况而言，没有任何依赖于该线程中“shared”的值的东西。你必须在线程中拥有保证进展，以确保实际赋值。在你的示例中，只有当“thread”终止时才能保证此进展：很可能是在线程函数结束时。再一次：你不知道线程何时调用你的函数。
volatile一样被处理。这部分基本上是Multithreading program stuck in optimized mode but runs normally in -O0和When to use volatile with multi threading?的重复。 - Peter Cordesatomic是正确的，其他方式即使使用volatile也会存在至少竞争访问的 UB（未定义行为）。 - Jarod42