4. RISC-V缓存一致性协议标准
各位同学，欢迎来到缓存一致性这一章。说实话，这是整个多核设计里最绕、也最容易出坑的地方。我自己刚入行时，就被一个隐蔽的一致性问题折腾了整整两周——两个核同时写同一个变量，结果读回来的数据对不上，查到最后才发现是协议状态机少了一个转移条件。
好，咱们今天就把这块硬骨头啃下来。先搞清楚一致性协议到底要解决什么问题，再来看它有哪些流派，最后聊聊强弱一致性模型——这些概念搞明白了，后面看具体协议实现才不会晕。
4.1 一致性协议要解决什么问题？
先问个问题：单核处理器需要缓存一致性吗？不需要。因为只有一个核，它自己写的自己读，不会有别人来抢数据。但到了多核系统里，情况就变了——每个核都有自己的私有缓存（L1），它们共享同一份内存数据。
你想想看，核A把变量x写成了5，这个新值还留在A的L1里，没写回内存。这时候核B去读x，它从自己的L1或者内存里读到的是旧值0。这就出问题了——两个核看到的数据不一致。
缓存一致性的核心目标：保证每个处理器核看到的共享数据视图是一致的。说白了，就是让所有核的缓存和内存之间，对同一个地址的读写行为符合一个统一的、可预期的规则。
具体来说，一致性协议要满足三个条件：
- 写传播（Write Propagation）：一个核的写操作，最终必须被其他核看到。
- 写串行化（Write Serialization）：所有核看到的写操作顺序必须一致。比如核A先写x=1，核B后写x=2，那么所有核要么先看到1再看到2，要么都看不到——但不能出现有的核看到1、有的核看到2这种乱序。
- 事务原子性（Transaction Atomicity）：读或写操作要么全部完成，要么完全不发生，不能出现半截子状态。
我在项目中遇到过最典型的一个坑：两个核同时对一个链表做插入操作，因为缓存一致性问题导致指针被部分覆盖，最后链表结构全乱了。嗯，这就是写传播没做好导致的。
4.2 一致性协议的两大分类
目前主流的一致性协议就两大类：窥探协议（Snooping Protocol）和目录协议（Directory Protocol）。它们解决同一个问题，但思路完全不同。
4.2.1 窥探协议
窥探协议的核心思想是：所有缓存控制器都监听总线上的事务。当某个核发起读写请求时，它会把请求广播到总线上，其他核的缓存控制器“偷听”到这个请求，然后根据自身缓存状态做出响应。
我习惯把窥探协议比作一个会议室——谁要发言（读写数据），就在会议室里喊一嗓子，所有人都能听到。优点是实现简单、延迟低；缺点是总线带宽有限，核数一多就撑不住了。
| 特性 | 窥探协议 | 目录协议 |
|---|---|---|
| 通信方式 | 广播（所有节点都听） | 单播/多播（只通知相关节点） |
| 可扩展性 | 差（总线带宽瓶颈） | 好（适合大规模系统） |
| 实现复杂度 | 低 | 高（需要维护目录表） |
| 典型应用 | 2~8核的小型SoC | 16核以上的服务器/数据中心 |
| 延迟 | 低（直接广播） | 中等（需要查目录再转发） |
避坑指南：我曾经在一个4核的RISC-V设计里用了窥探协议，一切正常。后来客户要求扩展到16核，我天真地以为只要把总线带宽翻倍就行——结果仿真时总线冲突率飙升到40%，性能反而下降了。所以，核数超过8个，我建议你直接上目录协议。
4.2.2 目录协议
目录协议的核心思路是：维护一个全局的目录表，记录每个缓存块被哪些核共享、处于什么状态。当某个核要读写数据时，它先查目录，然后只通知相关的核，而不是广播给所有人。
你想想看，这就像公司里有个前台——你要找某个同事，先问前台他在哪，然后直接去找他，不用在走廊里喊所有人。这样总线压力小得多，适合大规模系统。
目录协议的关键设计点有两个：
- 目录存储开销：每个缓存块都要在目录里占一个条目。对于N个核的系统，每个条目需要N个bit来记录共享者。所以核数越多，目录越大。
- 目录查找延迟：每次缓存缺失都要先查目录，多了一跳。不过这个延迟通常可以接受，因为避免了广播风暴。
我记得在做一个16核RISC-V处理器时，目录表占了将近2MB的SRAM。当时团队里有人觉得太浪费，想用哈希压缩——结果一致性出bug了。后来还是老老实实用了全相联目录。
4.3 缓存一致性模型
搞清楚了协议分类，咱们再来看看一致性模型。这个决定了什么时候能看到其他核的写结果。说白了，就是“多快能看到别人写的数据”。
4.3.1 强一致性模型
强一致性（也叫顺序一致性）要求：所有核的写操作，必须按照程序顺序被所有其他核看到。也就是说，如果核A先写x再写y，那么任何其他核看到y的新值时，一定也已经看到了x的新值。
这个模型很直观，程序员最喜欢——写代码时不用操心内存乱序问题。但代价是性能差，因为硬件必须做大量的同步和等待。
强一致性的典型实现：每个写操作都必须等所有其他核确认“我看到了”之后，才能继续执行下一条指令。这相当于给每个写操作加了一个全局同步屏障。
4.3.2 弱一致性模型
弱一致性就灵活多了。它允许写操作在没有同步操作的情况下，被其他核看到的顺序与程序顺序不同。但一旦遇到同步操作（比如fence指令、原子操作），就必须保证所有之前的写操作都对其他核可见。
我打个比方：强一致性就像排队买票，每个人必须等前面的人买完才能动；弱一致性就像自助餐厅，你可以先拿菜再拿饮料，只要在结账（同步点）时所有东西都齐了就行。
RISC-V里提供了fence指令来实现同步点。比如：
// 核A的代码
sw x1, 0(a0) // 写数据
fence // 同步屏障
sw x2, 0(a1) // 写标志位
// 核B的代码
lw t0, 0(a1) // 读标志位
fence // 同步屏障
lw t1, 0(a0) // 读数据这个例子里，如果没有fence，核B可能先看到标志位更新了，但数据还没写进去——这就是弱一致性带来的风险。加了fence之后，就能保证数据在标志位之前对核B可见。
| 模型 | 性能 | 编程难度 | 硬件复杂度 | 典型场景 |
|---|---|---|---|---|
| 强一致性 | 低（每次写都要同步） | 低（程序员不用操心） | 高（需要大量硬件同步） | 小型嵌入式系统 |
| 弱一致性 | 高（写操作可以乱序执行） | 高（需要手动加fence） | 低（硬件负担小） | 高性能计算、服务器 |
我的建议：如果你在做RISC-V多核设计，默认用弱一致性模型，然后在关键同步点手动加fence。这样性能好，而且可控。但一定要在文档里写清楚哪些地方需要fence——我曾经因为漏了一个fence，导致多线程程序跑了一天才出一次bug，查得我怀疑人生。
4.4 本章知识体系总览
下面这张图把一致性协议的核心脉络串起来了。你可以把它当作本章的“地图”——后面讲到具体协议时，随时回来对照。
这张图把本章的核心内容串起来了：从一致性协议的目标出发，分支出两大协议分类和两种一致性模型，最后落到具体的协议实现（MSI/MESI等）。后面几章我们会逐个深入这些协议的状态机和总线事务。