volatile与缓存一致性

最近在深入分析volatile关键字的实现原理，内存屏障、缓存一致性、store buffer、invalid queue等知识看了不少，但接触的资料比较零散，无法完整的把相关内容串联起来，所以抽空做些整理，也算对这段时间的学习做一个小结。

众所周知，volatile最主要的特性是保证了变量的可见性，即任意线程总能读到对volatile变量的最后写入（最新值）。而可见性正是依靠缓存一致性、内存屏障等机制协同运作来保证的。下面先就volatile与缓存一致性协议之间的关系分享下一点个人理解。

缓存一致性

计算机的存储结构在内存和CPU之间存在多级缓存，有些为CPU共享，如L3缓存；有些为CPU独享，如L1,L2缓存，缓存一致性问题即发生在独享缓存。引入多核后，一个数据可能在多个CPU的独享缓存存在拷贝，当其中一个CPU修改了本地缓存后，该数据在其他CPU缓存行的数据成为脏数据，相同数据出现了不一致。缓存一致性协议即为了保证多核场景下内存数据的在cpu cache的一致性。

MESI协议
MESI代表了缓存行的四种不同状态，状态标记以及触发状态转换的消息通知机制保证了缓存行的数据一致性。

状态：
已修改Modified (M)：缓存行是脏的（dirty），与主存的值不同。如果别的CPU内核要读主存这块数据，该缓存行必须回写到主存，状态变为共享(S).

独占Exclusive (E)：缓存行只在当前缓存中，但是干净的（clean）–缓存数据同于主存数据。当别的缓存读取它时，状态变为共享；当前写数据时，变为已修改状态。

共享Shared (S)：缓存行也存在于其它缓存中且是干净的。缓存行可以在任意时刻抛弃。

无效Invalid (I)：缓存行是无效的。这也是初始状态。

消息：
Read: CPU发起读取数据请求，请求中包含需要读取的数据地址。

Read Response: 作为Read消息的响应，该消息可能是内存响应的，也可能是某CPU响应的(比如该地址在某CPU Cache Line中为Modified状态，该CPU必须返回该地址的最新数据)。

Invalidate: 该消息包含需要失效的地址，所有的其它CPU需要将对应Cache置为Invalid状态

Invalidate Ack: 收到Invalidate消息的CPU在将对应Cache置为Invalid后，返回Invalid Ack

Read Invalidate: 相当于Read消息+Invalidate消息，即取得数据并且独占它，将收到一个Read Response和所有其它CPU的Invalid Ack

Writeback: 数据只写入Cache，仅当该数据块被替换时才将数据写回内存。（对比Write through：同时写入cache和内存）

volatile和MESI协议之间的关系

刚接触MESI协议时容易产生误解，以为是volatile关键字触发MESI机制来保证变量的可见性，实际没有这一层因果关系。下面简单总结下我对两者关系的一些理解：

1.MESI保障了多核场景的缓存一致性，是一套固有机制，无论是否声明volatile，只要变量在CPU缓存中就能通过这个协议保障可见性。但反过来，如果没有MESI协议，即使声明了volatile也无法保证变量的可见性；

2.既然有了MESI协议，为什么还要volatile？这是因为MESI本身存在一些性能问题（例如修改一个存在于其他CPU缓存的数据时，需要等待其他CPU的invalidate ack），因此额外引入了store buffer和invalidate queue等存储结构来优化性能。当数据仅存在于L1/L2 cache中时，MESI足可以保证volatile的内存语义，但如果数据存在于store buffer或者invalidate queue中时，仅靠MESI无法保证数据的一致性，这时需要引入内存屏障。

参考资料：

https://blog.csdn.net/xiaowenmu1/article/details/89705740

https://wudaijun.com/2019/04/cpu-cache-and-memory-model/#valine-comments

https://bk.tw.lvfukeji.com/baike-MESI%E5%8D%8F%E8%AE%AE?wprov=srpw1_5