现代cpu的cache一致性和happens before

现代计算机普遍都是多核,每个cpu都有自己的独立缓存(L1 Cache)用以提高访问数据速度,减少内存访问次数,但如果不采取对应措施就会带来数据不一致的问题,因此现代cpu采取了一系列措施来保证Cache数据的一致性。

最具代表性的就是MSIE协议,MSIE代表的是Cache存在的四种状态:

I=>Invalidate,代表当前cpu cache-line数据对应的内存源数据已经被其他cpu修改,当前cpu cache-line数据已经失效

E=>Exclusive,代表内存源数据此时只被当前cpu cache-line单独占有,其他cpu cache-line没有读取对应内存数据

S=>Share,代表当前cpu cache-line数据正在被其他cpu共享,此时所有cpu的缓存数据处于一致性状态

M=>Modify,代表当前cpu(cpu A) cache-line数据被修改,此时需要通过cpu总线发送invalid信号给所有cpu,通知如果cachce-line已经缓存了对应内存源数据,则标志当前缓存数据无效,下次要访问数据时候重新来cpu A的cache来取,此时会产生对应的化学效应,即相关cpu(包含cpu A) 状态都会变为S,同时最新数据刷新回主存(这个操作我们称作write back)

我们来举个例子:

假设两个cpu执行对应逻辑(假设a,b初始值为0):

cpuA                             cpuB

a=1 (标记为A.1)      while(b==0){//loop} (标记为B.1)

b=1 (标记为A.2)      assert(a==1) (标记为B.2)

执行时对应可能的cpu cache状态如下:

F2C33D7D-ACF3-4EA9-8331-8D45D903F92B.png

此时,所有cpu cache和内存数据达到暂时的一致性状态(当然由于执行的时序不同对应可能会出现不同的状态)

然而MSIE协议也会存在性能问题,其中一个写性能问题,譬如当前cpu在Modify时如果出现cache-miss情况,需要等待cpu先将数据加载到缓存,然后再进行修改,这个周期较长,且是一个阻塞操作,影响了整体性能

为解决这个问题,cpu设计时候引入了store buffer的概念,如图:

2B873A69-AAA6-4742-A09A-945F0FB6A78B.png

此时Modify的行为变为cpu先写入数据到store buffer,之后发出信号通知cache加载缓存数据,加载完毕后利用store-buffer修改当前cache数据以及状态,值得注意的是此时写store buffe和cache刷新是一个完全异步的过程,这样提高了写的效率,为保证一致性,当前cpu读取数据时候会优先去store-buffer里面读

然而由于写store-buffer和更新cache-line变成了一个异步操作,此时就引入了一个新的问题,即happens-before问题

首先我们来简单描述一下happens-before问题,同样以

cpuA                             cpuB

a=1 (标记为A.1)      while(b==0){//loop} (标记为B.1)

b=1 (标记为A.2)      assert(a==1) (标记为B.2)

这两组操作为例:

由于cpuA执行时A.1和A.2操作是有先后时序关系的,那么假设cpuB和cpuA在同一个时空中,这个先后关系在cpuB应该也是存在的,即如果在cpuB观测到b==1,则a==1也应该成立

然而store-buffer的引入使得系统违反了这样的时序性,如图:

6D6BD4E2-0A72-47CE-AA23-8A54E2F5288F.png

此时cpuA中由于a是异步刷新到cache的,所以出现了a的cache刷新晚于b刷新的情况(原因可能是a出现了cache-miss而b没有miss),结果就是从cpuB来看在b等于1之后a还是等于0

为了解决这个问题,我们需要在b的cache数据更新之前,强制把a的cache数据也更新了,并通知到其他cpu,为此cpu(x86)提供了sfence指令

cpuA                             cpuB

a=1 (标记为A.1)      while(b==0){//loop} (标记为B.1)

sfence

b=1 (标记为A.2)      assert(a==1) (标记为B.2)

此时执行时序如图:

9C6EF647-2281-4977-83BF-3346C2B8319B.png

这样就保证了时序性,解决了happens before问题

同样的x86 cpu还提供了lfence解决读层面的时序性问题,这里就不做详细介绍了,有兴趣的同学可以查阅相关资料

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,999评论 4 368
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,102评论 1 302
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 110,709评论 0 250
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,439评论 0 217
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,846评论 3 294
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,881评论 1 224
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,062评论 2 317
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,783评论 0 205
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,517评论 1 248
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,762评论 2 253
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,241评论 1 264
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,568评论 3 260
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,236评论 3 241
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,145评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,941评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,965评论 2 283
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,802评论 2 275

推荐阅读更多精彩内容