前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MESI 与 StoreBuffer 相互独立的猜想

MESI 与 StoreBuffer 相互独立的猜想

作者头像
执生
发布2021-03-02 16:48:36
5660
发布2021-03-02 16:48:36
举报
文章被收录于专栏:立权的博客

假设A是某缓存行的内容

CPU1 read A

CPU2 read A

CPU3 read A

CPU 3 在寄存器中修改 A 中内容,并且写入写缓存区StoreBuffer,假设修改是 ++A(就是A现在等于 A +1,图里放不下,简写成++A)

CPU1 和 上一步 CPU3 同样操作

总是得有一个CPU先将 StoreBuffer 中的修改写入到缓存的,假设是 CPU1,那么他在写入时需要向总线发送 Invalidate 请求

CPU2 和 CPU3 收到 Invalidate 之后,将自己的缓存行设置为无效。并且发回 Invalidate ACK

CPU 在收到所有 其他CPU 的 Invalidate ACK 响应之后,将缓存行状态设置为 Exclusive

因为CPU1 已经独占缓存行,那么他就可以将修改写入缓存行,缓存行变为Modified状态

当 CPU3 把自己的 ++A 修改写入缓存行时,他检查到自己A对应的缓存行是 Invalidated 状态,这个状态和未持有这个缓存行是等效的

所以他需要在总线上广播 Read - Invalidate 请求,这个请求是原子的,他会让其他CPU将最新的副本发送给自己,并且让他们把他们的该缓存行

设置为无效。同时返回一个 Invalidate ACK。

CPU3 收集到所有CPU的 Invalidate ACK 之后,将缓存行状态修改为 Exclusive

之后就可以如法炮制,将自己的修改刷入缓存,从E转变为M状态,个人认为 硬件架构 是用硬件机构来保证

E 到 M 状态的转换过程 不允许其他CPU打扰。所以从 Invalidate ACK 收集满到 写入修改的 过程是原子的。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021-02-18 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档