C++原子操作中释放序列相关技术问题问询

先给大家明确一下什么是释放序列：

在对原子对象M执行释放（release）操作A后，M的修改顺序中最长的连续子序列，由以下两部分组成：

• 执行A的同一线程执行的写入操作（该规则仅在C++20之前有效）
• 任意线程对M执行的原子读-改-写（RMW）操作
  这个子序列就被称为以A为首的释放序列。

下面针对几个常见问题逐一解答：

Q1：为什么我们需要释放序列这个概念？ #

简单来说，释放序列是为了让release操作的内存可见性能够“接力传递”，不用强制后续每一步修改都必须是release操作。举个实际场景：线程1对原子变量M做了一个release store，线程2对M做了一个relaxed RMW操作，线程3对M做了acquire load。如果没有释放序列的规则，线程3只能看到线程2的操作，没法保证能看到线程1在release之前的所有内存操作；但有了释放序列，线程2的RMW属于这个序列，线程3的acquire load就能“连”到线程1的release操作，确保内存可见性的传递。这就给并发代码的编写带来了不少灵活性，不用处处都加release语义的同步。

Q2：C++20是不是移除了第一部分（同一线程的写入）？ #

没错，C20确实删掉了这条规则。在C20之前，同一线程在release操作之后的连续写入也算释放序列的一部分，但这条规则实际用得不多，还会给编译器和硬件优化带来额外约束。调整之后，现在释放序列只包含后续的原子RMW操作，内存模型的规则更简洁，也更贴合硬件的实际执行特性。

Q3：为什么读-改-写（RMW）操作能加入释放序列，而纯写入操作不行？另外，宽松（relaxed）RMW为什么不需要是acquire加载和release存储就能形成链式传递？从硬件架构或者C++语言形式化的角度怎么理解？ #

这个问题可以从硬件和语言规则两个层面来拆解：

硬件架构角度 #

首先，RMW操作是“读取-修改-写入”原子执行的，硬件上这类操作通常会通过总线锁定或者缓存一致性协议（比如MESI）来保证原子性——执行过程中，其他核心根本没法修改这个内存位置。这种原子性意味着RMW操作会“继承”之前的内存状态，并且把自己的修改原子性地传递下去。

而纯写入操作没有读取步骤，只是直接覆盖内存值，硬件可能会对它做重排、合并等优化，导致它和之前的release操作之间的可见性链断裂。比如，一个纯write可能被硬件提前执行，或者在缓存里和其他写入合并，后续的acquire load就没法关联到最初的release操作了。

至于宽松RMW，虽然它没有acquire/release的语义，但它的原子性保证了它在修改顺序中是一个连续的节点。硬件上，RMW的原子执行会自然衔接前后的内存状态，相当于把释放序列的可见性链延续下去，不需要额外的内存屏障——因为原子RMW本身就不会和其他对同一原子变量的操作交叉执行，自然能维持序列的连续性。

C++语言形式化角度 #

从C++内存模型的规则来看，释放序列的核心作用是让后续的acquire操作能够“看到”最初release操作之前的所有内存操作。RMW操作的原子性意味着它在修改顺序中是不可分割的节点，而且标准明确规定，属于释放序列的RMW操作会把release的“释放语义”传递下去。

而纯写入操作没有这种原子性的衔接，它没法保证自己的写入是基于最初release之后的状态，所以不能成为释放序列的一部分。

宽松RMW之所以不需要acquire/release，是因为释放序列的规则本身就赋予了它传递可见性的能力——只要它属于某个release操作的释放序列，后续的acquire操作就能通过它关联到最初的release，不需要RMW本身带acquire或release语义。这是C++内存模型为了灵活性特意设计的，允许开发者在不需要强同步的情况下，依然能维持内存可见性的传递。

备注：内容来源于stack exchange，提问作者TSK