atomicity of memory accesses

文章目录

  • atomicity of memory accesses
    • ✅ 正确认识原子性的边界
      • 对于 **Load**:
      • ✅ 正确的原子性边界是:
      • 对于 **Store**:
      • ✅ 正确的原子性边界是:
    • 修正原文中的说法(对照分析)
    • ✅ 原子性边界最终澄清总结
  • 为什么 Sequential Consistency的两个核心约束 不提 read atomicity ?
    • 问题本质
    • ✅ 回答:因为 "Read Atomicity" 本身在 SC 中是隐含成立的,不需要单独强调
      • 思考路径如下:
      • 1. **Read 是不可观察的副作用**
      • 2. **读的行为完全依赖于写是否可见**
      • 3. **读操作在 SC 中没有并发可见性问题**
    • 举个例子说明
    • ✅ 总结
  • 从实现角度讲,并不需要额外引入“read atomicity”机制,只要确保读不会从“未完成的写”中读到值即可。

atomicity of memory accesses

原子性边界的界定—是理解 memory model 的核心之一。

SC 要求 atomicity of memory accesses , 下面将 memory accesses 进行拆解, 以 更深刻理解 SC 对 atomicity 的要求。


✅ 正确认识原子性的边界

对于 Load

步骤回顾

  1. 地址计算(EA)
  2. 发起访问(向 cache 发 load 请求) ← Issue
  3. 从 cache/mem 返回值 ← Perform point
  4. 写入目标寄存器

✅ 正确的原子性边界是:

  • 第 2 步(issue)第 3 步(fetch 到值)必须原子的部分
  • 原因:这是 load 真正与 memory hierarchy 交互的部分,如果其他 store 在这之间插入,会导致读取到错误值,破坏 SC。

❗注意:写入寄存器不是 memory model 的可见性关键,因此不是原子性边界的一部分。


对于 Store

步骤回顾

  1. 地址计算
  2. 指令 commit,进入 store buffer
  3. 从 store buffer 发起写 cache(store buffer flush)
  4. 写入缓存并完成 coherence 动作(例如 invalidate 或 update)Perform point

✅ 正确的原子性边界是:

  • 第 3 步(issue to cache)第 4 步(完成全局可见性)必须原子的部分
  • 原因:这决定了其他 core 能否读到这个 store 的值,如果这个过程可被插入或拆分,就会打破 memory consistency。

❗所以你说的 store 的 perform 阶段是必须原子的 —— 是完全正确的。


修正原文中的说法(对照分析)

我之前说:

“Load 的两个阶段(issue, completion)构成其原子性边界。”

→ ✅ 正确,但需要明确 “completion” 是指 从 cache 得到值,不是写入寄存器。

我之前说:

“Store 的边界是从 issue 到 perform(全局可见)。”

→ ✅ 正确,但更精确地讲是:从 store buffer flush 到 coherence 完成 是关键部分。


✅ 原子性边界最终澄清总结

操作类型 开始点 结束点
Load 发起 cache read 数据拿到为止
Store 发起 cache write 数据在所有核心可见为止

为什么 Sequential Consistency的两个核心约束 不提 read atomicity ?

你问得非常到位。这关系到 Sequential Consistency (SC) 模型中的核心假设和设计目标。


问题本质

你提到的两个约束其实是:

  1. 程序顺序对所有处理器都一致可见:每个处理器的指令(load/store)必须以程序写的顺序在系统中对所有处理器保持一致的顺序
  2. 写操作必须具有原子性(write atomicity):一旦某个处理器看到一个写(store)发生了,那么所有处理器必须同时看到这个写

于是问题来了:

为什么只强调了 Write Atomicity,而没有强调 Read Atomicity?


✅ 回答:因为 “Read Atomicity” 本身在 SC 中是隐含成立的,不需要单独强调


思考路径如下:

1. Read 是不可观察的副作用

读(load)操作不会对其他核心产生直接可观察的副作用,它只是读取某个内存位置的当前值,并不会改变共享状态。而写操作会改变共享状态,是全局可观察事件。

所以,SC 中只需要定义:写什么时候被"别人"看到;读自然是基于"可见的写"结果。


2. 读的行为完全依赖于写是否可见

在 SC 中,读到的值必须是某个已经完成的写,也就是说:

如果一个 core 看到 x = 1,那么在它看来 x = 1 这个写已经 globally visible 了(write atomicity 确保的)。

读到这个值是"合法"的前提是这个值是来自某个已经发生且"所有人都同意的"写。这一点正是 write atomicity 保证的。

所以 SC 中不需要额外声明 “read atomicity”——读只是在一组可见写中选一个。


3. 读操作在 SC 中没有并发可见性问题

  • 写的非原子性会导致 不同 core 看到不同写入值,所以必须强调 atomicity。
  • 但读不会被“别人看到”,所以不会产生一致性问题

因此,“read atomicity”没有意义:它不是一个互斥事件,也不需要所有 core "看到"某个读行为——它只是个本地动作。


举个例子说明

// P0
x = 1;
y = 1;

// P1
if (y == 1)
    assert(x == 1);

SC 要求:

  • P0 的 store 顺序是 x=1 → y=1
  • 如果 P1 看到 y1,那么由于 store 顺序一致性,它也必须看到 x1(因为 x=1 写在前)

关键是:

  • 写操作(x=1, y=1)必须在所有 core 看起来顺序一致
  • 读操作(y1, x1)只是根据这些写的“时间点”来决定自己的返回值,不存在“可见性”问题

✅ 总结

类型 是否强调原子性 原因
Write ✅ 强调 写影响全局状态,需要保证对所有核心同时可见
Read ❌ 不强调 读只是查询当前状态,不会影响其他核心,不存在多核心“看到”问题

所以:SC 模型中只需要定义 Write Atomicity,Read Atomicity 不是一个有意义的概念。


如果你在考虑更弱的 memory model(如 TSO, RCsc, ARM, RISC-V 等),那时读操作就可能变得“更复杂”,因为 load-store reordering 和缓存的本地视图都会造成读操作行为更微妙。在那种模型下,load 有时也需要 fence 或 acquire-semantics 来保证语义,但那是更进一步的问题了。你也可以继续问这方面的内容。

从实现角度讲,并不需要额外引入“read atomicity”机制,只要确保读不会从“未完成的写”中读到值即可。

你可能感兴趣的:(verilog,内存一致性)