MESI是一种广泛使用的写回策略的缓存一致性协议。
MESI协议中的状态
M:Modified被修改
E:Exclusive独享的
S:Shared共享的
I:Invalid无效的
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下是如何进行数据写回同步,保证数据的可见性,
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关键词保证可见性的原因。
volatile是Java虚拟机提供的轻量级的同步机制,它具备两种特性:保证共享变量对所有线程的可见性;禁止指令重排序,保证有序性;无法保证原子性(像count++就不是原子操作,包含了读 自加操作)