“int num” 中 Num++ 是原子的吗？

lock前缀可以应用于许多读-修改-写(内存目的地)指令，使整个操作相对于系统中所有可能的观察者(其他核心和 DMA 设备，而不是连接到 CPU 引脚的示波器)原子化。这就是它存在的原因。(另见 这个问答)。

所以 lock add dword [num], 1 是原子 。运行该指令的 CPU 核心会将缓存线路固定在其私有 L1缓存中的“修改状态”中，从负载从缓存读取数据开始，直到存储将结果提交回缓存。根据 MESI 缓存一致性协议(或多核 AMD/Intel CPU 分别使用的 MOESI/MESIF 版本)的规则，这可以防止系统中的任何其他缓存在从负载到存储的任何点上拥有缓存线路的副本。因此，其他核心的操作似乎发生在之前或之后，而不是期间。

如果没有 lock前缀，另一个核心可以获得缓存线路的所有权，并在加载之后但在存储之前对其进行修改，以便其他存储在加载和存储之间变得全局可见。其他几个答案都错了，并声称如果没有 lock，就会得到相同缓存行的相互冲突的副本。这种情况永远不可能发生在具有连贯缓存的系统中。

(如果一个 locked 指令操作跨越两条缓存线的内存，则需要做更多的工作来确保对象的两个部分的更改在传播到所有观察者时保持原子性，因此没有观察者可以看到撕裂。CPU 可能必须锁定整个内存总线，直到数据到达内存。不要让你的原子变量错位!)

请注意，lock前缀还会将指令转换为完整的内存屏障(如 MFence) ，停止所有运行时重新排序，从而产生循序一致性。(见 杰夫 · 普雷辛的优秀博客文章。他的其他文章也都很出色，清楚地解释了 很多中关于 无锁编程，无锁编程的一些好东西，从 x86和其他硬件细节到 C + + 规则。)

在单处理器机器上，或者在单线程进程 中，实际上没有 lock前缀的单个 RMW指令是 是原子指令。其他代码访问共享变量的唯一方法是让 CPU 进行上下文切换，这在指令执行过程中是不可能发生的。因此，纯 dec dword [num]可以在单线程程序及其信号处理程序之间进行同步，也可以在单核机器上运行的多线程程序中进行同步。请参阅 我对另一个问题的回答的后半部分及其下面的注释，我将在其中更详细地解释这一点。

返回 C + + :

使用 num++而不告诉编译器你需要它来编译成一个读-修改-写的实现是完全错误的:

;; Valid compiler output for num++
mov   eax, [num]
inc   eax
mov   [num], eax

如果您稍后使用 num的值，这种情况很有可能发生: 编译器将在增量之后将它保存在寄存器中。因此，即使您检查 num++如何自行编译，更改周围的代码也会影响它。

(如果以后不需要这个值，首选 inc dword [num]; 现代的 x86 CPU 运行内存-目标 RMW 指令的效率至少与使用三个单独的指令一样高。有趣的事实: gcc -O3 -m32 -mtune=i586实际上会发出这个，因为(Pentium) P5的超标量流水线没有像 P6和后来的微架构那样将复杂的指令解码成多个简单的微操作。更多信息请参见 阿格纳 · 福格的说明书/微架构指南，许多有用的链接请参见 X86标签 wiki (包括 Intel 的 x86 ISA 手册，可以免费获得 PDF 格式)。

不要将目标内存模型(x86)与 C + + 内存模型混淆

允许编译时重新排序 。使用 std: : atom 所获得的另一部分是对编译时重新排序的控制，以确保只有在执行其他操作之后，num++才能变得全局可见。

经典示例: 将一些数据存储到一个缓冲区中，供另一个线程查看，然后设置一个标志。即使 x86可以免费获得加载/发布存储，您仍然必须告诉编译器不要使用 flag.store(1, std::memory_order_release);重新排序。

您可能希望这段代码与其他线程同步:

// int flag;  is just a plain global, not std::atomic<int>.
flag--;           // Pretend this is supposed to be some kind of locking attempt
modify_a_data_structure(&foo);    // doesn't look at flag, and the compiler knows this.  (Assume it can see the function def).  Otherwise the usual don't-break-single-threaded-code rules come into play!
flag++;

但不会的。编译器可以自由地在函数调用中移动 flag++(如果它内联函数或者知道它不查看 flag)。然后它可以完全优化去修改，因为 flag甚至不是 volatile。

(不，C + + volatile不是 std: : atom 的有用替代品。Atom 的确使编译器假设可以异步地修改内存中的值，这与 volatile类似，但是它的意义远不止于此。(实际上，对于纯负载和纯存储操作有 之间的相似性挥发性 int 到标准: : 原子与 mo _ 弛豫，但对于 RMW 没有)。此外，volatile std::atomic<int> foo不一定与 std::atomic<int> foo相同，尽管当前的编译器不会优化原子(例如两个相同值的背靠背存储) ，因此易失性原子不会改变代码生成器

将非原子变量上的数据竞争定义为“未定义的行为”，这使得编译器仍然可以将负载和接收存储提升到循环之外，还可以对多个线程可能引用的内存进行许多其他优化。(有关 UB 如何启用编译器优化的更多信息，请参见 LLVM 博客。)

正如我所提到的，X86 lock前缀是一个完整的内存屏障，所以使用 num.fetch_add(1, std::memory_order_relaxed);在 x86上生成的代码与使用 num++生成的代码相同(默认是循序一致性) ，但它在其他架构(如 ARM)上可以更有效率。即使在 x86上，轻松也允许更多的编译时重新排序。

这就是 GCC 在 x86上对操作 std::atomic全局变量的一些函数所做的实际工作。

请参见在 Godbolt 编译器浏览器上精心格式化的源 + 汇编语言代码。您可以选择其他目标体系结构，包括 ARM、 MIPS 和 PowerPC，以查看从这些目标的原子获得哪种汇编语言代码。

#include <atomic>
std::atomic<int> num;
void inc_relaxed() {
num.fetch_add(1, std::memory_order_relaxed);
}


int load_num() { return num; }            // Even seq_cst loads are free on x86
void store_num(int val){ num = val; }
void store_num_release(int val){
num.store(val, std::memory_order_release);
}
// Can the compiler collapse multiple atomic operations into one? No, it can't.

# g++ 6.2 -O3, targeting x86-64 System V calling convention. (First argument in edi/rdi)
inc_relaxed():
lock add        DWORD PTR num[rip], 1      #### Even relaxed RMWs need a lock. There's no way to request just a single-instruction RMW with no lock, for synchronizing between a program and signal handler for example. :/ There is atomic_signal_fence for ordering, but nothing for RMW.
ret
inc_seq_cst():
lock add        DWORD PTR num[rip], 1
ret
load_num():
mov     eax, DWORD PTR num[rip]
ret
store_num(int):
mov     DWORD PTR num[rip], edi
mfence                          ##### seq_cst stores need an mfence
ret
store_num_release(int):
mov     DWORD PTR num[rip], edi
ret                             ##### Release and weaker doesn't.
store_num_relaxed(int):
mov     DWORD PTR num[rip], edi
ret

注意序列一致性存储之后是如何需要 MFENT (一个完全屏障)的。X86通常是强顺序的，但是允许 StoreLoad 重新排序。拥有存储缓冲区对于流水线式无序 CPU 的良好性能至关重要。Jeff Preshing 的 内存重新排序在行为中被捕获显示了使用 MFence 的 没有的结果，用真实的代码显示在真实的硬件上发生的重新排序。

关于@Richard Hodges 对 将标准: : 原子 ABC0操作合并为一条 num--;指令的编译器的回答:

关于同一主题的一个单独的问答: 为什么没有编译器合并冗余的标准: : 原子写，在这里我的回答重述了我在下面写的很多东西。

当前的编译器实际上并没有这样做(目前还没有) ，但这并不是因为它们不被允许这样做。C + + WG21/P0062R1: 编译器什么时候应该优化原子讨论了许多程序员的期望，即编译器不会进行“令人惊讶”的优化，以及标准可以为程序员提供哪些控制。N4455讨论了许多可以优化的例子，包括这一个。它指出，内联和常量传播可以引入像 fetch_or(0)这样的东西，它可以变成仅仅一个 load()(但仍然有获取和释放语义) ，即使原始源没有任何明显冗余的原子操作。

编译器没有这样做的真正原因是: (1)没有人编写复杂的代码，让编译器可以安全地进行编译(而不会出错) ，(2)它可能违反了 最小惊喜原则。无锁代码一开始就很难正确编写。因此，不要随便使用原子武器: 它们并不便宜，也没有太多优化。但是，使用 std::shared_ptr<T>避免冗余的原子操作并不总是那么容易，因为它没有非原子版本(尽管 其中一个答案提供了一种为 gcc 定义 shared_ptr_unsynchronized<T>的简单方法)。

返回到 num++; num-=2;编译，就像它是 num--一样: 编译器 是允许的执行此操作，除非 num为 volatile std::atomic<int>。如果可以进行重新排序，则 as-If 规则允许编译器在编译时决定 一直都是是否采用这种方式。没有什么能够保证观察者可以看到中间值(num++结果)。

也就是说，如果在这些操作之间没有全局可见的排序符合源的排序要求 (根据抽象机器的 C + + 规则，而不是目标体系结构) ，编译器可以发出一个单独的 lock dec dword [num]，而不是 lock inc dword [num]/lock sub dword [num], 2。

num++; num--不能消失，因为它仍然与查看 num的其他线程保持着 Synchronize With 关系，它既是一个获取加载，又是一个发布存储，不允许对该线程中的其他操作进行重新排序。对于 x86，这可能能够编译成 MFENT，而不是 lock add dword [num], 0(即 num += 0)。

正如在 PR0062中所讨论的，在编译时更积极地合并不相邻的原子操作可能是不好的(例如，一个进度计数器只在每次迭代结束时更新一次，而不是每次迭代) ，但它也可以帮助性能而不带来负面影响(例如，如果编译器可以证明另一个 shared_ptr对象在临时对象的整个生命周期中存在，那么在创建和销毁一个 shared_ptr副本时，跳过引用计数的原子 inc/dec)

当一个线程立即解锁和重新锁定时，即使 num++; num--合并也会损害锁实现的公平性。如果它实际上从来没有在高潮时释放，那么即使是硬件仲裁机制也不会给另一个线程在那个时候抓住锁的机会。

使用当前的 gcc6.2和 clang3.9，即使在最明显可优化的情况下使用 memory_order_relaxed，您仍然可以获得单独的 locked 操作。(Godbolt 编译器浏览器，这样你就可以看到最新的版本是否不同。)

void multiple_ops_relaxed(std::atomic<unsigned int>& num) {
num.fetch_add( 1, std::memory_order_relaxed);
num.fetch_add(-1, std::memory_order_relaxed);
num.fetch_add( 6, std::memory_order_relaxed);
num.fetch_add(-5, std::memory_order_relaxed);
//num.fetch_add(-1, std::memory_order_relaxed);
}


multiple_ops_relaxed(std::atomic<unsigned int>&):
lock add        DWORD PTR [rdi], 1
lock sub        DWORD PTR [rdi], 1
lock add        DWORD PTR [rdi], 6
lock sub        DWORD PTR [rdi], 5
ret