MSI/MESI:我们如何在共享状态下获得“读取想念”？

Question

在Jim的“缓存内存手册”(摘录如下)中，作者拥有MESI协议的表描述。在我看来，这张桌子看上去很不清楚，不幸的是，案文没有帮助。

第一个问题(图片上绿色)：

Is this right? -- a data block is in the cache of a CPU,
and it is in the shared state, but when the CPU reads it, 
the CPU gets read miss. 
How is this possible?

第二个问题(紫色)：

Who and when create all these messages "Read miss", etc.?
(afaik, the system bus just translates messages of others) 

最后，第三个问题(不是在图上)：

Do all these cache coherency protocols 
(MSI,MESI,MOESI,Firefly,Dragon...)
maintain sequential consistency memory model?
Are there protocols that maintain other consistency models?

​

​

Answer 1

对于第一个问题，虽然缓存中有一个数据块(处于共享状态)，但它是错误的块(即标记不匹配)，因此缓存丢失。在缓存丢失时，如果数据处于修改状态，则缓存仍然需要将数据写回内存。

对于第二个问题，每个总线都向缓存提供地址和请求信息(读或写)；系统总线从远程处理器提供地址和请求信息。命中或丢失取决于提供的地址是否是缓存中的命中。系统总线上的请求由远程处理器的缓存过滤。

在处理器1 (P1)读取时，如果P1的缓存命中，则不需要将信号发送到系统总线。在P1编写时，如果P1的缓存有命中且状态是排他的或修改的，则不需要向系统总线发送信号，但如果P1的缓存中的状态是共享的，则另一个(P0)缓存必须通知(通过系统总线)P1正在执行写操作，并且该地址的P0缓存中的任何条目都必须无效。

(请注意，“共享”状态并不一定意味着内存块存在于其他缓存中。大多数基于窥探的协议不允许系统总线在共享状态下丢弃缓存块。)

(顺便说一句，那本书给出的MESI协议有点不寻常。更常见的情况是，通过在块中没有发现其他缓存的读遗漏输入独占状态，这允许在以后的写入中修改静默更新，以及在处于共享状态的命中时，写不使用写入到内存。)

对于第三个问题，缓存一致性协议只解决一致性问题，而不是一致性问题。硬件提供的一致性模型决定了哪些活动可以按顺序缓冲和完成(以软件可见的方式)。例如，如果写失败不强制任何后续的读命中等待写入通知被所有远程缓存看到，这将有助于性能，但是这样会违反顺序一致性。

下面是一个示例，说明顺序一致性如何防止写入的缓冲：

P0在位置B (缓存命中)处读取"B_old“，将"A_new”写入位置A(缓存丢失)，然后读取位置B。

P1在位置A (缓存命中)处读取"A_old“，将"B_new”写入位置B(缓存丢失)，然后读取位置A。

如果对写入进行缓冲，并且允许读取不等待其他缓存识别到前面的写入，则P 0的B的第二读可以读取"B_old“(因为它仍然是缓存命中的)和P1的第二读A可以读取"A_old”(因为还没有看到P0的写入)。无法构造这些内存访问的顺序顺序，因此会违反顺序一致性。

但是，如果P0对B的第二读直到P1识别了P0对A的写(而P1的第二读直到P0识别了P1对B的写)，那么顺序排序是可能的。

如果P1在写B之前看到了P0对A的写，那么顺序排序是可能的，包括：

• 读"B_old"，P1.读"A_old"，P0.写"A_new"，P1.写"B_new"，P0读"B_new"，P1.读"A_new“
• 读"B_old"，P1.读"A_old"，P0.写"A_new"，P0读"B_old"，P1.写"B_new"，P1.读"A_new“

注意，硬件可以推测排序要求没有被违反，并重新排序完成内存访问；但是，它需要能够处理不正确的推测(例如，通过恢复到检查点)。(这方面的经典早期论文是“SC + ILP =RC吗？”[PDF格式])。

Answer 2

在缓存行和主存块之间有一对多的映射.共享的缓存行可能不是程序正在寻找的内存块。实际发生的情况是，您的程序想要的内存块，以及缓存中的内存块，虽然不同，但具有相同的缓存行索引。连续的内存块被映射到连续的缓存线，直到缓存线结束，而随后的内存块被映射到从第一条缓存线开始的缓存线。

我在这里找到了一个直观的解释：https://medium.com/breaktheloop/direct-mapping-map-cache-and-main-memory-d5e4c1cbf73e