内存模型

02 运行时 回答「下一步轮到哪个线程」，这一部分回答另一半：轮到的线程做一次原子读，能读到哪些值，以及读到之后线程之间多了什么因果关系。代码集中在 rt/atomic.rs（931 行）、rt/vv.rs（86 行）和 rt/synchronize.rs（63 行）三个文件，另有 rt/thread.rs 里每个线程的时钟和全局的 seq_cst_causality。

flowchart TB
  op["AtomicUsize::load / store / fetch_add / fence"] --> br["branch：调度点（fence 除外）"]
  br --> sy["synchronize：本线程时钟自增"]
  sy --> st["State：最近 7 次写的环形数组"]
  st --> m["match_load_to_stores / match_rmw_to_stores：列出候选写"]
  m --> path["Path 的 Load 分支：这一轮取第几个候选"]
  path --> ld["State::load / rmw：coherence、first_seen、Synchronize"]
  ld --> vv["线程的 causality 时钟（happens-before）"]
  vv --> chk["04 检测器：UnsafeCell、with_mut 用同一套时钟判竞争"]

五章：

1. 向量时钟与同步点：VersionVec 的三个操作；每线程 causality、released、dpor_vv 三套时钟；synchronize() 只在原子操作、fence、单元格访问前自增；Synchronize 怎样实现 Release / Acquire；spawn 与 unpark 带来的 happens-before。
2. 写历史与 coherence：State 与 Store 的字段；修改顺序用向量时钟表示的偏序；四条 coherence 规则各在哪几行；文件头那张 CDSChecker 规则清单里哪些是空的；7 次写的窗口（E6：连写 7 次后初值不再是候选）。
3. load 的候选：主线 2 的核心。match_load_to_stores 的三条排除规则逐条配实验；yield_now 之后不再给旧值（新实验：同一个模型加一次 yield_now，「对方已写、仍读到 0」这一种结果消失）；CoRR 的六种结果（E5）；unsync_load 不建分支。
4. RMW 与释放序列：match_rmw_to_stores 只给修改顺序上最新的写；成功的 RMW 继承所读写的 Synchronize 形成释放序列（实验：RMW 续上、普通写断开）；失败的 CAS 也只读最新写；compare_exchange_weak 不会伪失败（E16）；与 tokio #1788 的 fetch_add(0)。
5. fence 与 SeqCst：四种 fence 的实现与 Relaxed fence 的 panic；fence(SeqCst) 是对全局时钟的双向 join；SeqCst 访问的 seq_cst() 是空函数，只剩 load 匹配里的一条规则；SB、RWC、IRIW 三个 litmus 的实测结果；这段实现的历史（#108、#111、#220）。

不重讲的部分

• 五类 Ordering 的用法与配对：crossbeam 卷的本库里的内存序。本部分只讲 loom 怎么模拟这些语义。
• 「为什么 x86 上测不出、要靠 loom / Miri / TSan」：crossbeam 卷的怎么验证并发代码。
• dpor_vv 与回溯点：02 DPOR。它和本部分的 causality 是两套独立的时钟，只在 向量时钟与同步点 里并列介绍一次。
• SB / LB 两个 litmus 在 loom 能力边界里的位置：07 SeqCst 与 load buffering。本部分讲机制，那一章讲「这意味着什么」。

文档与代码的出入

演进

只列 git log -S 可查的事实；0.5.3、0.5.4 两个版本在 CHANGELOG 里有、仓库里没有对应 tag，版本号以 CHANGELOG 为准。

本部分的实验

机器 M2 Max（8P + 4E），macOS，rustc 1.99.1，loom =0.7.2，RUSTFLAGS="--cfg loom" cargo test --release --offline，每个实验目录单独的 CARGO_TARGET_DIR。loom 在一个 OS 线程上跑完所有模型线程，交错数是确定的，重跑结果相同；本部分只报告交错数和结果集合，不报告耗时。