原文地址：https://blog.fanscore.cn/p/34/

引言

本文以go1.14 darwin/amd64中的原子操作为例，探究原子操作的汇编实现，引出LOCK指令前缀、可见性、MESI协议、Store Buffer、Invalid Queue、内存屏障，通过对CPU体系结构的探究，从而理解以上概念，并在最终给出一些事实。

Go中的原子操作

我们以atomic.CompareAndSwapInt32为例，它的函数原型是：

func CompareAndSwapInt32(addr *int32, old, new int32) (swapped bool)

对应的汇编代码为：

// sync/atomic/asm.s 24行
TEXT ·CompareAndSwapInt32(SB),NOSPLIT,$0
	JMP	runtime∕internal∕atomic·Cas(SB)

通过跳转指令JMP跳转到了runtime∕internal∕atomic·Cas(SB)，由于架构的不同对应的汇编代码也不同，我们看下amd64平台对应的代码：

// runtime/internal/atomic/asm_amd64.s 17行
TEXT runtime∕internal∕atomic·Cas(SB),NOSPLIT,$0-17
	MOVQ	ptr+0(FP), BX // 将函数第一个实参即addr加载到BX寄存器
	MOVL	old+8(FP), AX // 将函数第二个实参即old加载到AX寄存器
	MOVL	new+12(FP), CX // // 将函数第一个实参即new加载到CX寄存器
	LOCK // 本文关键指令，下面会详述
	CMPXCHGL	CX, 0(BX) // 把AX寄存器中的内容(即old)与BX寄存器中地址数据(即addr)指向的数据做比较如果相等则把第一个操作数即CX中的数据(即new)赋值给第二个操作数
	SETEQ	ret+16(FP) // SETEQ与CMPXCHGL配合使用，在这里如果CMPXCHGL比较结果相等则设置本函数返回值为1，否则为0(16(FP)是返回值即swapped的地址)
	RET // 函数返回

从上面代码中可以看到本文的关键：LOCK。它实际是一个指令前缀，它后面必须跟read-modify-write指令，比如：ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, XCHG。

LOCK实现原理

在早期CPU上LOCK指令会锁总线，即其他核心不能再通过总线与内存通讯，从而实现该核心对内存的独占。

这种做法虽然解决了问题但是性能太差，所以在Intel P6 CPU（P6是一个架构，并非具体CPU）引入一个优化：如果数据已经缓存在CPU cache中，则锁缓存，否则还是锁总线。

Cache Coherency

CPU Cache与False Sharing 一文中详细介绍了CPU缓存的结构，CPU缓存带来了一致性问题，举个简单的例子：

// 假设CPU0执行了该函数
var a int = 0
go func fnInCpu0() {
    time.Sleep(1 * time.Second)
    a = 1 // 2. 在CPU1加载完a之后CPU0仅修改了自己核心上的cache但是没有同步给CPU1
}()
// CPU1执行了该函数
go func fnInCpu1() {
    fmt.Println(a) // 1. CPU1将a加载到自己的cache，此时a=0
    time.Sleep(3 * time.Second)
    fmt.Println(a) // 3. CPU1从cache中读到a=0，但此时a已经被CPU0修改为0了
}()

上例中由于CPU没有保证缓存的一致性，导致了两个核心之间的同一数据不可见从而程序出现了问题，所以CPU必须保证缓存的一致性，下面将介绍CPU是如何通过MESI协议做到缓存一致的。

MESI是以下四种cacheline状态的简称：

M(Modified)：此状态为该cacheline被该核心修改，并且保证不会在其他核心的cacheline上
E(Exclusive)：标识该cacheline被该核心独占，其他核心上没有该行的副本。该核心可直接修改该行而不用通知其他核心。
S(Share)：该cacheline存在于多个核心上，但是没有修改，当前核心不能直接修改，修改该行必须与其他核心协商。
I(Invaild)：该cacheline无效，cacheline的初始状态，说明要么不在缓存中，要么内容已过时。

核心之间协商通信需要以下消息机制：

Read: CPU发起数据读取请求，请求中包含数据的地址
Read Response: Read消息的响应，该消息有可能是内存响应的，有可能是其他核心响应的（即该地址存在于其他核心上cacheline中，且状态为Modified，这时必须返回最新数据）
Invalidate: 核心通知其他核心将它们自己核心上对应的cacheline置为Invalid
Invalidate ACK: 其他核心对Invalidate通知的响应，将对应cacheline置为Invalid之后发出该确认消息
Read Invalidate: 相当于Read消息+Invalidate消息，即当前核心要读取数据并修改该数据。
Write Back: 写回，即将Modified的数据写回到低一级存储器中，写回会尽可能地推迟内存更新，只有当替换算法要驱逐更新过的块时才写回到低一级存储器中。

手画状态转移图

深入理解原子操作的本质

这里有个存疑的地方：CPU从内存中读到数据I状态是转移到S还是E，查资料时两种说法都有。个人认为应该是E，因为这样另外一个核心要加载副本时只需要去当前核心上取就行了不需要读内存，性能会更高些，如果你有不同看法欢迎在评论区交流。

一些规律

CPU在修改cacheline时要求其他持有该cacheline副本的核心失效，并通过Invalidate ACK来接收反馈
cacheline为M意味着内存上的数据不是最新的，最新的数据在该cacheline上
数据在cacheline时，如果状态为E，则直接修改;如果状态为S则需要广播Invalidate消息，收到Invalidate ACK后修改状态为M;如果状态为I（包括cache miss）则需要发出Read Invalidate

Store Buffer

当CPU要修改一个S状态的数据时需要发出Invalidate消息并等待ACK才写数据，这个过程显然是一个同步过程，但这对于对计算速度要求极高的CPU来说显然是不可接受的，必须对此优化。
因此我们考虑在CPU与cache之间加一个buffer，CPU可以先将数据写入到这个buffer中并发出消息，然后它就可以去做其他事了，待消息响应后再从buffer写入到cache中。但这有个明显的逻辑漏洞，考虑下这段代码：

a = 1
b = a + 1

假设a初始值为0，然后CPU执行a=1，数据被写入Store Buffer还没有落地就紧接着执行了b=a+1，这时由于a还没有修改落地，因此CPU读到的还是0，最终计算出来b=1。

为了解决这个明显的逻辑漏洞，又提出了Store Forwarding：CPU可以把Buffer读出来传递(forwarding)给下面的读取操作，而不用去cache中读。
深入理解原子操作的本质

这倒是解决了上面的漏洞，但是还存在另外一个问题，我们看下面这段代码：

a = 0
flag = false
func runInCpu0() {
    a = 1
    flag = true
}

func runInCpu1() {
    while (!flag) {
   	continue
    }
    print(a)
}

对于上面的代码我们假设有如下执行步骤：

假定当前a存在于cpu1的cache中，flag存在于cpu0的cache中，状态均为E。
cpu1先执行while(!flag)，由于flag不存在于它的cache中，所以它发出Read flag消息
cpu0执行a=1，它的cache中没有a，因此它将a=1写入Store Buffer，并发出Invalidate a消息
cpu0执行flag=true，由于flag存在于它的cache中并且状态为E，所以将flag=true直接写入到cache，状态修改为M
cpu0接收到Read flag消息，将cache中的flag=true发回给cpu1，状态修改为S
cpu1收到cpu0的Read Response：flat=true，结束while(!flag)循环
cpu1打印a，由于此时a存在于它的cache中a=0，所以打印出来了0
cpu1此时收到Invalidate a消息，将cacheline状态修改为I，但为时已晚
cpu0收到Invalidate ACK，将Store Buffer中的数据a=1刷到cache中

从代码角度看，我们的代码好像变成了

func runInCpu0() {
    flag = true
    a = 1
}

好像是被重新排序了，这其实是一种 伪重排序，必须提出新的办法来解决上面的问题

写屏障

CPU从软件层面提供了 写屏障(write memory barrier) 指令来解决上面的问题，linux将CPU写屏障封装为smp_wmb()函数。写屏障解决上面问题的方法是先将当前Store Buffer中的数据刷到cache后再执行屏障后面的写入操作。

SMP: Symmetrical Multi-Processing，即多处理器。

这里你可能好奇上面的问题是硬件问题，CPU为什么不从硬件上自己解决问题而要求软件开发者通过指令来避免呢？其实很好回答：CPU不能为了这一个方面的问题而抛弃Store Buffer带来的巨大性能提升，就像CPU不能因为分支预测错误会损耗性能增加功耗而放弃分支预测一样。

还是以上面的代码为例，前提保持不变，这时我们加入写屏障：

a = 0
flag = false
func runInCpu0() {
    a = 1
    smp_wmb()
    flag = true
}

func runInCpu1() {
    while (!flag) {
   	continue
    }
    print(a)
}

当cpu0执行flag=true时，由于Store Buffer中有a=1还没有刷到cache上，所以会先将a=1刷到cache之后再执行flag=true，当cpu1读到flag=true时，a也就=1了。

有文章指出CPU还有一种实现写屏障的方法：CPU将当前store buffer中的条目打标，然后将屏障后的“写入操作”也写到Store Buffer中，cpu继续干其他的事，当被打标的条目全部刷到cache中，之后再刷后面的条目。

Invalid Queue

上文通过写屏障解决了伪重排序的问题后，还要思考另一个问题，那就是Store Buffer size是有限的，当Store Buffer满了之后CPU还是要卡住等待Invalidate ACK。Invalidate ACK耗时的主要原因是CPU需要先将自己cacheline状态修改I后才响应ACK，如果一个CPU很繁忙或者处于S状态的副本特别多，可能所有CPU都在等它的ACK。

CPU优化这个问题的方式是搞一个Invalid Queue，CPU先将Invalidate消息放到这个队列中，接着就响应Invalidate ACK。然而这又带来了新的问题，还是以上面的代码为例

a = 0
flag = false
func runInCpu0() {
    a = 1
    smp_wmb()
    flag = true
}

func runInCpu1() {
    while (!flag) {
   	continue
    }
    print(a)
}

我们假设a在CPU0和CPU1中，且状态均为S，flag由CPU0独占

CPU0执行a=1，因为a状态为S，所以它将a=1写入Store Buffer，并发出Invalidate a消息
CPU1执行while(!flag)，由于其cache中没有flag，所以它发出Read flag消息
CPU1收到CPU0的Invalidate a消息，并将此消息写入了Invalid Queue，接着就响应了Invlidate ACK
CPU0收到CPU1的Invalidate ACK后将a=1刷到cache中，并将其状态修改为了M
CPU0执行到smp_wmb()，由于Store Buffer此时为空所以就往下执行了
CPU0执行flag=true，因为flag状态为E，所以它直接将flag=true写入到cache，状态被修改为了M
CPU0收到了Read flag消息，因为它cache中有flag，因此它响应了Read Response，并将状态修改为S
CPU1收到Read flag Response，此时flag=true，所以结束了while循环
CPU1打印a，由于a存在于它的cache中且状态为S，所以直接将cache中的a打印出来了，此时a=0，这显然发生了错误。
CPU1这时才处理Invalid Queue中的消息将a状态修改为I，但为时已晚

为了解决上面的问题，CPU提出了读屏障指令，linux将其封装为了smp_rwm()函数。放到我们的代码中就是这样：

...
func runInCpu1() {
    while (!flag) {
   	continue
    }
    smp_rwm()
    print(a)
}

当CPU执行到smp_rwm()时，会将Invalid Queue中的数据处理完成后再执行屏障后面的读取操作，这就解决了上面的问题了。

除了上面提到的读屏障和写屏障外，还有一种全屏障，它其实是读屏障和写屏障的综合体，兼具两种屏障的作用，在linux中它是smp_mb()函数。
文章开始提到的LOCK指令其实兼具了内存屏障的作用。

几个问题

问题1: CPU采用MESI协议实现缓存同步，为什么还要LOCK

答：

MESI协议只维护缓存一致性，与可见性有关，与原子性无关。一个非原子性的指令需要加上lock前缀才能保证原子性。

问题2: 一条汇编指令是原子性的吗

read-modify-write 内存的指令不是原子性的，以INC mem_addr为例，我们假设数据已经缓存在了cache上，指令的执行需要先将数据从cache读到执行单元中，再执行+1，然后写回到cache。
对于没有对齐的内存，读取内存可能需要多次读取，这不是原子性的。（在某些CPU上读取未对齐的内存是不被允许的）
其他未知原因…

问题3: Go中的原子读

我们看一个读取8字节数据的例子，直接看golang atomic.LoadUint64()汇编：

// uint64 atomicload64(uint64 volatile* addr);
1. TEXT runtime∕internal∕atomic·Load64(SB), NOSPLIT, $0-12
2.	MOVL	ptr+0(FP), AX // 将第一个参数加载到AX寄存器
3.	TESTL	$7, AX // 判断内存是否对齐
4.	JZ	2(PC) // 跳到这条指令的下两条处，即跳转到第6行
5.	MOVL	0, AX // crash with nil ptr deref 引用0x0地址会触发错误
6.	MOVQ	(AX), M0 // 将内存地址指向的数据加载到M0寄存器
7.	MOVQ	M0, ret+4(FP) // 将M0寄存器中数据(即内存指向的位置)给返回值
8.	EMMS // 清除M0寄存器
9.	RET

第3行TESTL指令对两个操作数按位与，如果结果为0，则将ZF设置为1，否则为0。所以这一行其实是判断传进来的内存地址是不是8的整数倍。

第4行JZ指令判断如果ZF即零标志位为1则执行跳转到第二个操作数指定的位置，结合第三行就是如果传入的内存地址是8的整数倍，即内存已对齐，则跳转到第6行，否则继续往下执行。

关于内存对齐可以看下我这篇文章：理解内存对齐。

虽然MOV指令是原子性的，但是汇编中貌似没有加入内存屏障，那Golang是怎么实现可见性的呢？我这里也并没有完全的理解，不过大概意思是Golang的atomic会保证顺序一致性。

问题4：Go中的原子写

仍然以写一个8字节数据的操作为例，直接看golang atomic.LoadUint64()汇编：

TEXT runtime∕internal∕atomic·Store64(SB), NOSPLIT, $0-16
	MOVQ	ptr+0(FP), BX
	MOVQ	val+8(FP), AX
	XCHGQ	AX, 0(BX)
	RET

虽然没有LOCK指令，但XCHGQ指令具有LOCK的效果，所以还是原子性而且可见的。

总结

这篇文章花费了我大量的时间与精力，主要原因是刚开始觉得原子性只是个小问题，但是随着不断的深入挖掘，翻阅无数资料，才发现底下潜藏了无数的坑。
深入理解原子操作的本质

由于精力原因本文还有一些很重要的点没有讲到，比如acquire/release 语义等等。

另外客观讲本文问题很多，较真的话可能会对您造成一定的困扰，建议您可以将本文作为您研究计算机底层架构的一个契机，自行研究这方面的技术。

参考资料

内存屏障的来历
MESI协议 – 维基百科，自由的百科全书
c++ – Does golang atomic.Load have a acquire semantics? – Stack Overflow
golang-notes/memory_barrier.md at master · cch123/golang-notes · GitHub

引言