MESI 协议简介
MESI 协议
MESI 协议其实是 CPU Cache 的有限状态机，一共有 4 个状态（MESI 就是状态的首字母）：
- M（Modified，已修改）： 表明 Cache 块被修改过，但未同步回内存；
- E（Exclusive，独占）： 表明 Cache 块被当前核心独占，而其它核心的同一个 Cache 块会失效；
- S（Shared，共享）： 表明 Cache 块被多个核心持有且都是有效的；
- I（Invalidated，已失效）： 表明 Cache 块的数据是过时的。
在 “独占” 和 “共享” 状态下，Cache 块的数据是 “清” 的，任何读取操作可以直接使用 Cache 数据；
在 “已失效” 和 “已修改” 状态下，Cache 块的数据是 “脏” 的，它们和内存的数据都可能不一致。在读取或写入 “已失效” 数据时，需要先将其它核心 “已修改” 的数据写回内存，再从内存读取；
在 “共享” 和 “已失效” 状态，核心没有获得 Cache 块的独占权（锁）。在修改数据时不能直接修改，而是要先向所有核心广播 RFO（Request For Ownership）请求 ，将其它核心的 Cache 置为 “已失效”，等到获得回应 ACK 后才算获得 Cache 块的独占权。这个独占权这有点类似于开发语言层面的锁概念，在修改资源之前，需要先获取资源的锁；
在 “已修改” 和 “独占” 状态下，核心已经获得了 Cache 块的独占权（锁）。在修改数据时不需要向总线发送广播，能够减轻总线的通信压力。
事实上，完整的 MESI 协议更复杂，但我们没必要记得这么细。我们只需要记住最关键的 2 点：
- 关键 1 - 阻止同时有多个核心修改的共享数据： 当一个 CPU 核心要求修改数据时，会先广播 RFO 请求获得 Cache 块的所有权，并将其它 CPU 核心中对应的 Cache 块置为已失效状态；
- 关键 2 - 延迟回写： 只有在需要的时候才将数据写回内存，当一个 CPU 核心要求访问已失效状态的 Cache 块时，会先要求其它核心先将数据写回内存，再从内存读取。
提示： MESI 协议在 MSI 的基础上增加了 E（独占）状态，以减少只有一份缓存的写操作造成的总线通信。
MESI 协议有一个非常 nice 的在线体验网站，你可以对照文章内容，在网站上操作指令区，并观察内存和缓存的数据和状态变化。网站地址：https://www.scss.tcd.ie/Jeremy.Jones/VivioJS/caches/MESI.htm
MESI 协议在线模拟
4.4 写缓冲区 & 失效队列
MESI 协议保证了 Cache 的一致性，但完全地遵循协议会影响性能。因此，现代的 CPU 会在增加写缓冲区和失效队列将 MESI 协议的请求异步化，以提高并行度：
- 写缓冲区（Store Buffer）
由于在写入操作之前，CPU 核心 1 需要先广播 RFO 请求获得独占权，在其它核心回应 ACK 之前，当前核心只能空等待，这对 CPU 资源是一种浪费。因此，现代 CPU 会采用 “写缓冲区” 机制：写入指令放到写缓冲区后并发送 RFO 请求后，CPU 就可以去执行其它任务，等收到 ACK 后再将写入操作写到 Cache 上。
- 失效队列（Invalidation Queue）
由于其他核心在收到 RFO 请求时，需要及时回应 ACK。但如果核心很忙不能及时回复，就会造成发送 RFO 请求的核心在等待 ACK。因此，现代 CPU 会采用 “失效队列” 机制：先把其它核心发过来的 RFO 请求放到失效队列，然后直接返回 ACK，等当前核心处理完任务后再去处理失效队列中的失效请求。
写缓冲区 & 失效队列
事实上，写缓冲区和失效队列破坏了 Cache 的一致性。 举个例子：初始状态变量 a 和变量 b 都是 0，现在 Core1 和 Core2 分别执行这两段指令，最终 x 和 y 的结果是什么？
Core1 指令
a = 1; // A1
x = b; // A2
Core2 指令
b = 2; // B1
y = a; // B2
我们知道在未同步的情况下，这段程序可能会有多种执行顺序。不管怎么执行，只要 2 号指令是在 1 号指令后执行的，至少 x 或 y 至少一个有值。但是在写缓冲区和失效队列的影响下，程序还有以意料之外的方式执行：
|
执行顺序（先不考虑 CPU 超前流水线控制） |
结果 |
|---|---|
|
A1 → A2 → B1 → B2 |
x = 0, y = 1 |
|
A1 → B1 → A1 → B2 |
x = 2, y = 1 |
|
B1 → B2 → A1 → A2 |
x = 1, y = 0 |
|
B1 → A1 → B2 → A2 |
x = 2, y = 1 |
|
A2 → B1 → B2 → A1（A1 与 A2 重排） |
x = 0, y = 0 |
|
Core2 也会出现相同的情况，不再赘述 |
x = 0, y = 0 |
上图。
写缓冲区造成指令重排
可以看到：从内存的视角看，直到 Core1 执行 A3 来刷新写缓冲区，写操作 A1 才算真正执行了。虽然 Core 的执行顺序是 A1 → A2 → B1 → B2，但内存看到的顺序却是 A2 → B1 → B2 → A1，变量 a 写入没有同步给对变量 a 的读取，Cache 的一致性被破坏了。
5. 总结
- 1、在 CPU Cache 的三级缓存中，会存在 2 个缓存一致性问题：
- 纵向 - Cache 与内存的一致性问题： 在修改 Cache 数据后，如何同步回内存？
- 横向 - 多核心 Cache 的一致性问题： 在一个核心修改 Cache 数据后，如何同步给其他核心 Cache？
- 2、Cache 与内存的一致性问题有 2 个策略：
- 写直达策略： 始终保持 Cache 数据和内存数据一致，在每次写入操作中都会写入内存；
- 写回策略： 只有在脏 Cache 块被替换出去的时候写回内存，减少写回内存的次数；
- 3、多核心 Cache 一致性问题需要满足 2 点特性：
- 写传播（总线嗅探）： 每个 CPU 核心的写入操作，需要传播到其他 CPU 核心；
- 事务串行化（总线仲裁）： 各个 CPU 核心所有写入操作的顺序，在所有 CPU 核心看起来是一致。
- 4、MESI 协议能够满足以上 2 点特性，通过 “已修改、独占、共享、已失效” 4 个状态实现了 CPU Cache 的一致性；
- 5、现代 CPU 为了提高并行度，会在增加 写缓冲区 & 失效队列 将 MESI 协议的请求异步化， 从内存的视角看就是指令重排，破坏了 CPU Cache 的一致性。
