为何fetch_sub不属于释放操作？其内存序参数有何意义？

引自《C++ Concurrency in Action》示例5.9

带有memory_order_acquire语义的fetch_sub操作不会与任何操作同步，尽管它会存储值，因为它不是释放操作。同样地，存储操作无法与带有memory_order_release语义的fetch_or操作同步，因为fetch_or的读取部分不是获取操作。

我难以理解上述段落。既然带有memory_order_acquire语义的fetch_sub操作不会与任何操作同步，为何fetch_sub的接口仍为我们保留如下内存序参数？

T fetch_sub( T arg, std::memory_order order = std::memory_order_seq_cst ) noexcept;

别急，这里的关键是要区分同步（synchronizes-with）关系和内存可见性约束，还有原子操作本身的读写特性。

首先，fetch_sub是一个读-改-写（RMW）操作，它包含两个核心部分：读取当前原子变量的值，然后写入计算后的新值。当你指定memory_order_acquire时，这个内存序只作用于它的读取阶段——也就是说，在这个fetch_sub之后的所有读操作，都不能被编译器或CPU重排到这个操作之前，并且它能确保看到所有在它之前对该原子变量的写操作的结果。但因为它的写入部分没有release语义，所以它没法和其他线程的acquire操作建立synchronizes-with同步关系。

那为什么接口还要保留这个参数？主要有这几个原因：

• 细粒度的内存控制需求：虽然memory_order_acquire的fetch_sub不能建立跨线程的同步关系，但它依然能提供获取语义的内存屏障，防止后续操作被重排到它前面。在某些场景下，你可能不需要跨线程同步，只需要保证当前线程内的操作顺序，或者依赖原子变量本身的可见性（原子操作的读写本身就是原子的，即使没有同步关系也能保证最终一致性）。
• API设计的统一性：所有原子RMW操作（比如fetch_add、fetch_or、compare_exchange_weak等）都遵循同样的接口模式，这样开发者不需要记忆不同操作的参数差异，代码也更易读、易维护。
• 支持更有用的内存序组合：你可能会用到memory_order_acq_rel这种组合内存序——它的读取部分是acquire语义，写入部分是release语义，这样就能同时建立同步关系并保证操作顺序。接口保留参数就是为了支持这类实用的组合，而memory_order_acquire只是其中一个可选选项，单独使用时虽不能同步，但依然有其存在的价值。

举个简单例子：假设你有一个原子计数器，线程A用fetch_sub(1, memory_order_release)减少计数，线程B用fetch_sub(1, memory_order_acquire)获取当前计数。虽然线程B的操作不能和线程A的操作建立同步关系，但线程B依然能看到线程A对计数器的修改（原子操作的可见性保证），同时线程B后续的读操作不会被重排到fetch_sub之前，这能保证线程B在拿到计数器的值后，后续逻辑能基于这个值正确执行。

内容的提问来源于stack exchange，提问作者choxsword