MESI缓存一致性原理讲解

概念

        MESI是一种广泛使用的写回策略的缓存一致性协议。

 

MESI协议中的状态

M: 被修改（Modified)	该缓存行只被缓存在该CPU的缓存中，并且是被修改过的（dirty),即与主存中的数据不一致，该缓存行中的内存需要在未来的某个时间点（允许其它CPU读取请主存中相应内存之前）写回（write back）主存。 当被写回主存之后，该缓存行的状态会变成独享（exclusive)状态。
E: 独享的（Exclusive)	该缓存行只被缓存在该CPU的缓存中，它是未被修改过的（clean)，与主存中数据一致。该状态可以在任何时刻当有其它CPU读取该内存时变成共享状态（shared)。 同样地，当CPU修改该缓存行中内容时，该状态可以变成Modified状态。
S: 共享的（Shared)	该状态意味着该缓存行可能被多个CPU缓存，并且各个缓存中的数据与主存数据一致（clean)，当有一个CPU修改该缓存行中，其它CPU中该缓存行可以被作废（变成无效状态（Invalid））。
I: 无效的（Invalid）	该缓存是无效的（可能有其它CPU修改了该缓存行）。

 

利用例子分析MESI的工作原理

 

利用对变量count自增的程序，来理解MESI的工作过程，明白多CPU下是如何进行数据写回同步，保证数据的可见性，

具体CPU如何从主内存中加载变量进行运行的过程，在CPU缓存架构中有详解，这里不做过多的解释

 

1.假设CPU1率先抢到时间片，当变量count加载至CPU缓存中时，会将count的使用标志为（E独占：首次加载会将变量置为独占，也就说明没有其他CPU进行加载）

 

2.CPU2也获得时间片，把变量count加载缓存中，此时count的使用标志为（E独占），并发送消息至总线，告知其他CPU读取了变量的值，各CPU通过时刻监听（总线嗅探机制）获得到此变量已被多个CPU所加载，那么此时CPU2就会将自身count的使用标志置为（S共享），CPU1也会将变量的使用标志也会置为（S）

 

3.CPU1从缓存中加载count至寄存器中进行自增操作，执行完毕之后，count = 0 -> 1，此时由于count的值发生了变化，因此CPU1中变量count使用标志应为（M修改），此时CPU1会发送消息至总线，告知其他线程已经修改了变量count 的值，其他CPU嗅探到值的修改，就会将自身变量count的使用标志置为（I无效）

 

4.CPU1会将M状态的变量立刻写回至主内存中，写回完毕之后，CPU1会将使用状态置为（E独享），发送消息至总线，告知其他CPU已经写回完毕，其他CPU会再此从主内存中读取变量count的值，读取完毕之后，也会发送消息至总线，其他CPU嗅探到之后将自身变量count置为（S共享），自身变量的使用状态也会置为（S共享）

 

存在的疑问：

多个CPU同时都将变量置为M修改状态，那怎么办？

首先多个CPU都想将变量置为M修改状态，那么系统会有裁决机制，保证只有一个CPU能够操作成功，因此不会存在多个M状态的数据

 

MESI操作的基本单位：缓存行（CPU缓存中的最小存储单元）

缓存行的最小存储单元大小：32bit，64bit，128bit（因系统而定）

机械硬盘的最小存储单元：簇

 

 

MESI缓存一致性协议失效的原因

    缓存一致性协议失效的后果：当MESI失效之后，那么系统会自动将启用总线加锁机制，那么执行效率则会大打折扣。

    失效的情况：

    1.当缓存行存储的数据超过最小存储单元大小时（数据长度存储跨越多个缓存行的情况），就会导致MESI操作缓存行无效，导致MESI缓存一致性协议失效；

    2.系统不支持缓存一致性协议。

 

缓存行的概念：多个数据可以存储在一个缓存行，一个数据可以存储在多个缓存行（此种情况会导致MESI失效）

 

 

总线加锁机制

    对主内存数据进行加锁和解锁操作，当加锁之后，此数据不允许其他线程进行读写，只能等加锁线程操作完毕进行解锁之后才能进行操作。

 

 

Java中volatile关键词保证可见性原理

       MESI缓存一致性协议底层是通过#Lock的指令进行触发的，而volatile关键词修饰之后的变量，编译为指令集执行是，会加上#Lock进行修饰，用来触发缓存一致性协议，而且#Lock指令修饰之后，置为M（修改状态）的变量，会强制立刻写入主内存中，并且发送消息至总线，其他加载此变量的线程，就会将工作内存中变量的使用状态修改为I（无效状态），此时线程就被迫需要重新从主内存中读取该变量的值，这就是volatile关键词保证可见性的原因。