CPU缓存一致性原理

这篇具有很好参考价值的文章主要介绍了CPU缓存一致性原理。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

CPU缓存一致性原理

在本站的文章CPU缓存那些事儿中, 介绍了cpu的多级缓存的架构和cpu缓存行cache line的结构。CPU对于缓存的操作包含读和写,读操作在cache line中有所涉及,在本文中,将重点讨论CPU对于缓存进行写时的行为。

单核CPU对高速缓存的读操作

CPU对于高速缓存的读操作的过程在之前的文章中有提到过,这里梳理一下其流程:

  • 1.首先对于一个内存地址,CPU会按照索引规则(直接映射/多路组相连/全相连)优先去cache line中进行检索。
  • 2.如果检索到了,意味着该内存地址的内容已经存在于cache中,则直接读取内容到CPU中,流程结束。如果没有检索到,进行步骤3。
  • 3.此时确认内存的数据不在cache line中,如果cache已经存满或者已经被其他内存地址映射,则进入步骤4,如果cache line中还有空位,则进入步骤5.
  • 4.执行缓存淘汰策略,腾出位置
  • 5.加载内存数据到cache line中,将cache块上的内容读取到cpu中。

对于单核CPU, 对cache的读操作的流程如下所示:

CPU缓存一致性原理,缓存,java,开发语言

单核CPU对于高速缓存的写操作

CPU对于高速缓存的写操作比读操作要复杂一些,写操作会修改cache中的数据,而这一数据最终需要同步到内存中,在同步到内存这个点上,写操作的策略可以分为写直达策略写回策略。注意这里的讨论仍然是针对单核CPU而言的。

写直达策略(Write-Through)

写直达策略的思想是对于写入操作,同时修改cache中的数据内存中的数据,使得cache和内存中的数据保持一致。这将使得cache和内存拥有数据的强一致性

写直达策略中写数据的流程可以被细化为下列的步骤:

  • 1.判断待写入的数据是否已经存在于cache中。如写入的数据已经存在于cache中,则跳转到步骤2,否则跳转到步骤3。
  • 2.将数据写入cache中。
  • 3.将数据写入内存。

而写直达策略中读数据的流程并没有任何改变,因为cache和内存的数据是强一致的。

写直达策略的流程概括为如下所示:

CPU缓存一致性原理,缓存,java,开发语言

对于写直达策略,读cache的流程并没有任何改变,这一点和写回策略是有区别的。

写直达的优缺点如下:

优点:对于写操作而言,可以保证内存和高速缓存内容的强一致性

缺点:由于每次写入操作都需要将数据写入内存,使得写操作的耗时增加,失去了高速缓存的高效性

写回策略(Write-Back)

写直达策略的思想是当需要修改cache时,延迟修改内存。在每个cache line上增加了Dirty的标记,当修改了cache中的内容时,会将Dirty标记置位,表明它的数据和内存数据不一致。注意此时,并不会立即写回内存。只有当cache块被替换出去时,才会回写到内存中。这其实是一种异步的思想,其相较于写直达也要复杂一些。写回策略实现的是一种最终一致性

写回策略是由读和写配合完成的。

对于写回策略中的写操作,其流程如下:

  • 1.首先判断写操作的地址是否存在于cache中,如存在,进入步骤6,否则进入步骤2。
  • 2.如果写操作的地址不在cache中,则尝试读取内存数据到cache中。这里需要判断cache此时是否已经满或者被占用。如果已经满或者被占用,则进入步骤3,否则进入步骤5。
  • 3.如果cache此时是否已经满或者被占用,则使用替换策略挪出空位。此时还需要判断被替换出的cache line是否为脏数据,如果是脏数据,则进入步骤4,否则进入步骤5
  • 4.将被替换出的cache line的数据写回内存中。
  • 5.读取内存块的数据到cache line中。
  • 6.将数据写入cache中
  • 7.将cache line标记为脏数据。

由于替换策略也可能发生在读操作中,因此对于写回策略中的读操作也发生了修改,其流程如下所示:

  • 1.首先对于一个内存地址,CPU会按照索引规则(直接映射/多路组相连/全相连)优先去cache line中进行检索。
  • 2.如果检索到了,意味着该内存地址的内容已经存在于cache中,则直接读取内容到CPU中,流程结束。如果没有检索到,进行步骤3。
  • 3.此时确认内存的数据不在cache line中,如果cache已经存满或者已经被其他内存地址映射,则进入步骤4,如果cache line中还有空位,则进入步骤6.
  • 4.执行缓存淘汰策略,腾出位置,此时需要判断被替换出的cache line是否为脏数据,如果是,则进入步骤5,否则进入步骤6.
  • 5.将脏数据写回到内存中。
  • 6.加载内存数据到cache line中,将cache块上的内容读取到cpu中。

写回策略的读写操作的流程如下所示:

CPU缓存一致性原理,缓存,java,开发语言

多CPU核的缓存一致性问题。

上面的写直达策略写回策略可以解决单核CPU的cache和内存的一致性问题。而现代的CPU往往都是多核CPU,每个核心都拥有其自己的cache。那么对于写操作而言,除了保证本CPU的cache和内存的一致性,还需要保证其它CPU的cache和内存的一致性问题。

MESI协议就是用来解决这个问题的。

MESI协议是一种用于保证缓存一致性的协议,其对应了CPU cache的四种状态,每个字母代表了一种状态,其含义如下:

  • M(Modified,已修改): 表明 Cache 块被修改过,但未同步回内存;
  • E(Exclusive,独占): 表明 Cache 块被当前核心独占,而其它核心的同一个 Cache 块会失效;
  • S(Shared,共享): 表明 Cache 块被多个核心持有且都是有效的;
  • I(Invalidated,已失效): 表明 Cache 块的数据是过时的。

MESI 协议其实是 CPU Cache 的有限状态机,其四种状态的转化如下图所示:

CPU缓存一致性原理,缓存,java,开发语言

对于MESI协议,有一个可视化的网站可以演示其过程,网址:https://www.scss.tcd.ie/Jeremy.Jones/VivioJS/caches/MESIHelp.htm。

下面我们借助该网站来理解MESI每个状态的变换过程。

独占状态E转已修改状态M E->M

如下图所示,此时cpu0上有a0的缓存,a0的缓存状态是独占状态E。

CPU缓存一致性原理,缓存,java,开发语言

此时cpu0执行write a0操作,由于其它cpu上没有a0数据,状态E转为状态M:

CPU缓存一致性原理,缓存,java,开发语言

已修改状态M转共享状态S,M->S

如下图所示,此时cpu0上有a0的缓存,a0的缓存状态是已修改状态M:

CPU缓存一致性原理,缓存,java,开发语言

随后cpu1上执行read a0的操作,则cpu 0上的a0从状态M转为状态S:

CPU缓存一致性原理,缓存,java,开发语言

共享状态S转已失效状态I, S->I

如下图所示,此时cpu0上有a0的缓存,其状态为S。除此以外,cpu1上也有a0的缓存。

CPU缓存一致性原理,缓存,java,开发语言

此时cpu1上执行write a0的操作,则cpu0上的a0状态从S转为了I:

CPU缓存一致性原理,缓存,java,开发语言

共享状态S转独占状态E, S->E

如下图所示,此时cpu0上有a0的缓存,其状态为S。除此以外,cpu1上也有a0的缓存。

CPU缓存一致性原理,缓存,java,开发语言

此时cpu1上执行write a0的操作,则cpu1上的a0状态从S转为了E:

CPU缓存一致性原理,缓存,java,开发语言

已失效状态I转独占状态E,I->E

状态I转状态E有两种路径,第一种是通过Processor Read, 此时a0数据仅存在于cpu0的cache中:

CPU缓存一致性原理,缓存,java,开发语言

cpu0执行read a0操作,a0状态从I转为了E:

CPU缓存一致性原理,缓存,java,开发语言

第二种是通过process write, 注意此时a0数据存在于cpu0和cpu1的cache中:

CPU缓存一致性原理,缓存,java,开发语言

cpu0执行write a0操作,a0状态从I转为了E:

CPU缓存一致性原理,缓存,java,开发语言

已失效状态I转共享状态S,I->S

此时cpu0上a0的状态是I, 而cpu1上a0的状态是E:

CPU缓存一致性原理,缓存,java,开发语言

此时cpu0执行read a0操作,cpu0上的a0从I转为S:

CPU缓存一致性原理,缓存,java,开发语言

独占状态E转已失效状态I,E->I

此时cpu0上的有a0的缓存,且状态为E,其它cpu上没有a0的缓存:

CPU缓存一致性原理,缓存,java,开发语言

此时cpu1执行write a0的操作,此时cpu0上a0的状态从E转为I:

CPU缓存一致性原理,缓存,java,开发语言

已修改状态E转共享状态S,E->S

如下图所示,此时cpu0的独占a0:

CPU缓存一致性原理,缓存,java,开发语言

此时cpu1执行read a0的操作:

CPU缓存一致性原理,缓存,java,开发语言

独占状态M转失效状态I, M->I

此时cpu0上拥有a0的缓存,且状态为M,其它cpu上没有a0的缓存:

CPU缓存一致性原理,缓存,java,开发语言

此时cpu1执行write a0的操作,则cpu0上a0缓存的状态从独占(M)转为了失效(I):

CPU缓存一致性原理,缓存,java,开发语言

已失效状态I转已修改状态M,I->M

此时cpu0上a0缓存的状态是I,其它cpu上没有a0的缓存:

CPU缓存一致性原理,缓存,java,开发语言

此时cpu0执行write a0, 则cpu0上的a0从I转为了E:

CPU缓存一致性原理,缓存,java,开发语言

写缓冲区和失效队列

写缓冲区和失效队列实际上是对MESI的优化策略。

写缓冲区(Store Buffer)

从上面的对于MESI的理解中,不难发现,MESI协议其实并不高效。例如当CPU1将要修改cache line时,需要广播RFO获得独占权,当收到其它cpu核的ACK之前,CPU1只能空等。 这对于CPU1而言,是一种资源的浪费。写缓冲区就是为了解决这个问题的。当CPU核需要写操作时,会将写操作放入缓冲区中,然后就可以执行其它指令了。当收到其它核心的ACK后,就可以将写入的内容写入cache中。

失效队列(Invalidation Queue)

写缓冲区是对写操作发送命令时的优化,而失效队列则是针对收写操作命令时的优化。

对于其它的CPU核心而言,在其收到RFO请求时,需要更新当前CPU的cache line状态,并回复ACK。然而在收到RFO请求时,CPU核心可能在处理其它的事情,不能及时回复

写缓冲区和失效队列将RFO请求的收发修改为了异步的,这实际上实现的是一种最终一致性。这也会引入新的问题,即CPU对于指令会有重排。如果有一些程序对于内存序有要求,那么就需要进行考虑。

考虑下面的场景,cpu0和cpu1分别执行下面的指令:

cpu0上指令

a = 1  //A1
x = b  //A2

cpu1上指令

b = 1 //B1
y = a //B2

CPU缓存一致性原理,缓存,java,开发语言

由于store-buffer的存在,尽管A1操作先于A2操作之前发生,但是A1操作完成时间可能晚于A2,如下表中反应的顺序:

顺序 cpu0 cpu1
0 a=1写入store buffer b = 1写入store buffer
1 x=b
2 y = a
3 b = 1操作完成
4 a=1操作完成

尽管A1操作发生于B2之前,但是由于写操作的异步特性,当执行到y=a时,读取到的还是旧值。同理x=b也可能读取到旧的值。

对于这种cpu层面的指令重排问题,则需要内存屏障进行解决。

总结

  • 对于单核cpu,写操作需要考虑cache和内存的一致性,通常有写直达和写回两种策略。
  • 对于多核cpu,除了cache和内存的一致性需要保证,还需要保证每个cpu的cache的数据的一致性。
  • MESI协议就是一种解决多核cpu缓存一致性的算法
  • 为了改善MESI的效率,引入了store-buffer和Invalidation Queue,提升了效率,但是也引入了指令重排的问题。通常可以使用内存屏障解决。

参考文献

https://www.scss.tcd.ie/Jeremy.Jones/VivioJS/caches/MESIHelp.htm
https://blog.csdn.net/weixin_46215617/article/details/115433851?share_token=0637ba7e-fc4b-4d21-8d6b-000301e7fe3e
https://juejin.cn/post/7158395475362578462
https://blog.51cto.com/qmiller/5285102文章来源地址https://www.toymoban.com/news/detail-662306.html

到了这里,关于CPU缓存一致性原理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 缓存数据一致性探究

    缓存是一种较低成本提升系统性能的方式,自它面世第一天起就备受广大开发者的喜爱。然而正如《人月神话》中的那句经典的“没有银弹”中所说,软件工程的设计没有银弹。 就像每一次发布上线修复问题的同时,也极易引入新的问题,自缓存诞生的第一天起, 缓存与数

    2024年02月16日
    浏览(35)
  • 深入理解高并发下的MySQL与Redis缓存一致性问题(增删改查数据缓存的一致性、Canal、分布式系统CAP定理、BASE理论、强、弱一致性、顺序、线性、因果、最终一致性)

    一些小型项目,或极少有并发的项目,这些策略在无并发情况下,不会有什么问题。 读数据策略:有缓存则读缓存,然后接口返回。没有缓存,查询出数据,载入缓存,然后接口返回。 写数据策略:数据发生了变动,先删除缓存,再更新数据,等下次读取的时候载入缓存,

    2024年03月20日
    浏览(54)
  • Redis之缓存一致性

    按照缓存更新的方式大致分为: 内存淘汰、过期删除、主动更新。 利用 Redis 的内存淘汰策略,当内存不足时自动进行淘汰部分数据,下次查询时更新缓存,一致性差,无维护成本。 因为 Redis 是基于内存的,如果内存超过限定值( Redis 配置文件的 maxmemory 参数决定 Redis 最大内

    2024年02月07日
    浏览(51)
  • 【Redis】之数说缓存一致性

    对于使用 Redis 作为缓存来说,如何保证数据库和缓存数据一致性是个麻烦的问题。对于缓存和数据库的操作,主要有以下两种方式: 先删缓存,再更新数据库; 先更新数据库,再删除缓存; 这两种方式都存在缓存一致性问题,下面我们就分析一下如何解决这两种方式的缓存

    2024年02月13日
    浏览(42)
  • 缓存和数据库一致性

    项目的难点是如何保证缓存和数据库的一致性。无论我们是先更新数据库,后更新缓存还是先更新数据库,然后删除缓存,在并发场景之下,仍然会存在数据不一致的情况(也存在删除失败的情况,删除失败可以使用异步重试解决)。有一种解决方法是延迟双删的策略,先删

    2024年01月17日
    浏览(45)
  • Redis---缓存双写一致性

    目录 一、什么是缓存双写一致性呢?  1.1 双检加锁机制  二、数据库和缓存一致性的更新策略 2.1、先更新数据库,后更新缓存  2.2 、先更新缓存,后更新数据库  2.3、先删除缓存,在更新数据库 延时双删的策略:  2.4.先更新数据库,在删除缓存(常用) 2.5、实际中是不可

    2024年02月15日
    浏览(49)
  • Redis缓存(双写一致性问题)

    前言 : 什么是缓存? 缓存就像自行车,越野车的避震器 举个例子:越野车,山地自行车,都拥有\\\"避震器\\\", 防止 车体加速后因惯性,在酷似\\\"U\\\"字母的地形上飞跃,硬着陆导致的 损害 ,像个弹簧一样; 同样,实际开发中,系统也需要\\\"避震器\\\",防止过高的数据访问猛冲系统,导致其操作线程无法

    2024年02月02日
    浏览(64)
  • Redis缓存双写一致性

    如果redis中有数据:需要和数据库中的值相同 如果redis中无数据:数据库中的值要是最新值,且准备回写redis 缓存按照操作来分,可细分为两种: 只读缓存和读写缓存 只读缓存很简单:就是Redis只做查询,有就是有,没有就是没有,不会再进一步访问MySQL,不再需要会写机制

    2023年04月17日
    浏览(46)
  • 缓存和数据库一致性问题分析

    目录 1、数据不一致的原因 1.1 并发操作 1.2 非原子操作 1.3 数据库主从同步延迟 2、数据不一致的解决方案 2.1 并发操作 2.2 非原子操作 2.3 主从同步延迟 2.4 最终方案 3、不同场景下的特殊考虑 3.1 读多写少的场景 3.2 读少写多的场景 导致缓存和数据库数据不一致的原因有三个

    2024年02月14日
    浏览(42)
  • 28.Netty源码之缓存一致性协议

    Mpsc 的全称是 Multi Producer Single Consumer,多生产者单消费者。 Mpsc Queue 可以保证多个生产者同时访问队列是线程安全的,而且同一时刻只允许一个消费者从队列中读取数据。 Netty Reactor 线程中任务队列 taskQueue 必须满足多个生产者可以同时提交任务,所以 JCTools 提供的 Mpsc Queu

    2024年02月13日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包