基于广义缓存一致性的高效可扩展同步（OSDI 2026）

原题：Efficient and Scalable Synchronization via Generalized Cache Coherence

一句话总结：在以太网连接的解聚共享内存中，传统锁会把一次同步拆成多次高延迟一致性事务；GCP 将锁语义直接并入缓存一致性协议，用等待队列扩展时间范围、用可变大小共享内存列表扩展数据范围，Soul 在读密集的 MIND-KVS 上达到 8 个 blade、37.1 Mops，并较分层锁提升 1–2 个数量级，但写密集负载仍受以太网互连延迟限制。

问题与动机

解聚共享内存把计算 blade 与内存 blade 分开，并通过网络提供统一的共享内存视图。MIND 等系统以页为单位维护目录式缓存一致性；一次跨 blade 的权限转移通常需要多次以太网往返。锁若直接建立在这层缓存一致性之上，就会把锁变量访问、临界区数据访问和锁交接叠加成一串一致性事务。

论文在 MIND 上观察到，Cohort 等高性能锁在 8 个 blade 时会把请求延迟推高到超过 1 ms，锁操作占据大部分时间（图 3）。绕过一致性的独立锁服务又会失去缓存局部性和“锁与数据一起获取”等优化，并受可编程交换机资源限制。

作者的核心判断是：缓存一致性和读写锁都维护单写者多读者（SWMR）不变量。前者只在一条指令和固定缓存行范围内维护，后者则把范围扩展到一个临界区和任意大小的共享数据。因此，直接扩展缓存一致性协议比在其上再叠加锁服务更合适。

关键观察 / 隐含假设

观察 1：分层锁的通信量随参与 blade 数量增长。 在不同读写比例下，Pthread、Percpu 等锁产生与参与者数量相关的缓存一致性事务；MCS 等队列锁虽能减少部分争用，仍需多次事务（图 2b、图 11）。
- 依赖假设：跨 blade 的缓存一致性往返延迟远高于本地缓存访问。
- 可能失效场景：互连延迟接近片上 NUMA，或工作负载主要在单 blade 内执行时，协议扩展的收益会缩小。
观察 2：读多写少时，锁和数据可以长期留在多个缓存中。 Soul 在没有写者时不主动失效读者缓存，YCSB-C 在 8 个 blade 上达到 37.1 Mops（图 9）。
- 依赖假设：共享对象具有时间局部性，且读写比例足够偏向读取。
- 可能失效场景：频繁写入、读写交替或共享对象快速变化时，缓存失效仍会主导延迟。
假设 1：目录协议可以安全地保存等待中的冲突请求。 GCP 以等待队列延迟冲突请求，并要求持有者显式释放；模型检查覆盖 MSI、MESI、MOSI、MOESI 四类协议，但模型规模只有单地址、两个数据值和三个 blade，证据强度为中。
假设 2：锁保护的数据能够提前注册为共享内存列表。 共享列表只负责把数据区域与锁绑定，动态改变对象范围时需要 GCP_destroy/GCP_create，这会触发广播和缓存刷新。证据强度为中。

核心方法

GCP（Generalized cache-Coherence Protocol）保留目录式一致性协议的状态机，并加入两类扩展。第一类是等待队列：GCP_acquire 异步申请 M 或 S 权限，冲突请求进入队列；持有者调用 GCP_release 后，目录才继续处理下一个请求；GCP_is_acquired 用于检查申请是否完成。这样，权限不再只覆盖一条指令，而是覆盖整个临界区。

第二类是共享内存列表：一个逻辑缓存项可包含多个不重叠、任意大小的地址区间。锁交接时，这些区间被一起移动或失效，避免锁变量和受保护数据之间的额外一致性事务。等待队列负责正确性，共享列表主要减少数据移动次数。

Soul 将 GCP 实现于 MIND 的 DRAM 缓存控制器和可编程交换机上。等待队列放在当前写者所在的 compute blade，而不是交换机中。目录只记录队列持有者和版本号；队列转移要求两端版本一致，以保证目录转发的请求已被旧持有者处理。每页队列长度按 blade 数量固定分配，8-blade 配置下交换机元数据开销低于 8%。

Soul 通过用户态库提供 POSIX pthread_rwlock 和 Rust std::sync::RwLock API。由于 GCP 的请求者是缓存而非线程，库采用两级锁：先用本地软件锁区分同一 blade 上的线程，再用 GCP 锁维护跨 blade 的 SWMR。锁管理器限制 GCP 页占本地 DRAM cache 的比例，默认上限为 6%；超限时回退到传统锁。

设计取舍

协议层集成换取实现复杂度。 锁与缓存一致性共享状态机，能复用数据预取和局部性优化，但需要扩展目录状态、处理驱逐、队列转移和失败恢复。
队列靠近当前写者换取状态迁移逻辑。 队列出队无需额外网络往返，但读者集合变化时必须把队列转移到下一个写者，并用版本号处理并发转发。
共享列表换取动态对象更新成本。 固定对象可一次获取锁和数据；对象范围变化需要广播、刷新缓存并重新创建列表。论文未实现写者原地修改列表。
透明线程级 API 换取两级锁开销。 同一 blade 内仍依赖软件锁，并将本地锁复用次数限制为 64，以避免远端请求长期饥饿。

实验与结果

在 8 个 blade 的 MIND-KVS 上，Soul 在只读 YCSB-C 达到 37.1 Mops，较 Pthread、Cohort、MCS 和 Lock Service 高 2–3 个数量级（图 9）。
在单锁、4KB 共享数据的微基准中，Soul 在 8 个 blade 上的锁与数据获取平均延迟为 100–200 µs，约比最快的分层锁低一个数量级；每次获取只需一个一致性事务（图 11）。
去除锁与数据合并获取后，仍需额外网络往返；去除时间局部性优化后，获取延迟上升 1–2 个数量级（图 12）。
Soul 的目录和内核元数据开销在 8-blade 配置下低于 8% 的交换机存储，compute blade 侧共享列表开销不超过 0.3%（§4.1–§4.2）。
在 gem5 模拟的 16-host CXL 3.0 集群上，SoulCXL 较最接近的基线在 MIND-KVS Twitter 工作负载上最多快 1.7×，在 YCSB 上最多快 2.0×（图 13）；该结果依赖 300 ns 的乐观 host-to-host 往返延迟（§6）。

论断—证据表

论断	证据	评测边界	置信度
把同步并入缓存一致性可减少跨 blade 通信	Soul 在 8 blade 上每次锁与数据获取只触发一个一致性事务，图 11	MIND、页粒度、最多 8 个 blade	强
缓存锁和数据的时间局部性适合读密集工作负载	YCSB-C 达到 37.1 Mops，图 9；消融见图 12	MIND-KVS、读为主；写密集负载不扩展	强
GCP 的协议元数据开销可控	§4.1–§4.2 报告交换机低于 8%、内核不超过 0.3%	8-blade、4KB 页、固定长度队列	中
设计可迁移到 CXL 一致性互连	SoulCXL 图 13–16	gem5 模拟、16 hosts、单一 CXL 配置	中

批判性分析

论证链条

论文的链条在以太网解聚内存场景中是闭合的：测量显示分层锁重复触发一致性事务；GCP 将等待和数据范围纳入同一协议；微基准确认事务数下降，端到端应用也获得收益。读写锁语义与 SWMR 的对应关系为设计提供了简洁抽象。

但“适用于任意目录式协议”的结论主要由有限状态模型支持。模型检查只覆盖三个 blade、单地址和两个数据值；复杂多地址交互、队列资源耗尽和跨锁依赖仍依赖实现测试或应用责任。

假设压力测试

写密集的 MIND-KVS 在增加 blade 后并不扩展，论文将原因归于以太网的 5–10 µs 缓存延迟。这说明 GCP 消除了冗余事务，却没有消除真实写共享造成的串行化。CXL 模拟显示互连缩短后，Percpu 可能因争用加剧而退化，不能简单把以太网结果外推到 CXL。

共享内存列表要求区域不重叠且静态程度较高。动态容器、频繁扩容或对象生命周期复杂时，刷新成本可能进入关键路径。Soul 的锁管理器能回收应用失败后的资源，但 compute blade 或 memory blade 故障沿用了 MIND 的不可恢复模型；更强的故障模型尚未覆盖。

实验可信度

实验同时包含 MIND-KVS、Kyoto Cabinet、Twitter trace、YCSB 和 TPC-C，并有事务数、延迟、消融和元数据开销，足以支持“在给定平台和工作负载上减少同步开销”的结论。对照包括分层锁和独立 Lock Service，比较面较完整。

主要边界是硬件规模有限：真实系统最多 8 个 blade、80 个 worker cores，CXL 部分是 trace replay 模拟。没有报告多租户隔离、不同队列策略、队列积压、动态共享列表更新频率或更高并发下的交换机资源余量。

系统性缺陷

Soul 的透明 API 仍要求 Rust 用户在创建锁时提供受保护对象；C API 对动态对象范围的处理更受限。队列策略目前固定为 FIFO，超出 GCP cache 配额会回退到传统锁，可能造成同一应用内性能不连续。论文未讨论锁升级、超时、try-lock、优先级反转和详细可观测性。

局限与后续工作

局限 1：动态共享对象更新昂贵。 GCP_destroy 与 GCP_create 会广播并刷新缓存；可验证的后续方向是测量不同更新频率下的 P99 延迟，并实现写者原地扩展共享列表。
局限 2：写共享仍受互连延迟限制。 在 Twitter cluster 10、cluster 53 和 YCSB-A/B 上，Soul 随 blade 数增加并不扩展；需要在真实 CXL 设备或更低延迟互连上验证队列与局部性优化。
局限 3：协议验证规模有限。 应扩大模型检查的地址数、blade 数和队列状态，并针对资源耗尽、进程退出和并发队列转移加入故障注入。
局限 4：锁 API 覆盖有限。 未来可加入 try-lock、超时、显式 abort 和读写优先级，并比较这些策略对公平性与尾延迟的影响。

Awesome System Papers Wiki

探索

paper-osdi26-yu-yanpeng