为什么编译器不合并冗余的STD：：Atomic写？

Question

#include <atomic>
std::atomic<int> y(0);
void f() {
  auto order = std::memory_order_relaxed;
  y.store(1, order);
  y.store(1, order);
  y.store(1, order);
}

如果变量是易变的，那么显然没有任何优化是适用的。在我的情况下是什么阻止了它？

下面是编译器资源管理器中的代码。

Answer 1

C++11/C++14标准确实允许将三个存储区折叠/合并为最终值的一个存储区。即使在这种情况下：

  y.store(1, order);
  y.store(2, order);
  y.store(3, order); // inlining + constant-folding could produce this in real code

该标准并不保证在y（带有原子加载或CAS）上旋转的观察者会看到y==2。依赖于此的程序将有数据竞争bug，但只有普通bug类型的竞争，而不是C++未定义行为类型的数据竞争。（它是UB，只有非原子变量）。一个期望有时看到它的程序甚至不一定是错误的。（参见下面的进度条。）

C++抽象机器上可能的任何排序都可以（在编译时）作为总是发生的排序。这就是行动中的好像规则。在本例中，就好像所有三个存储都是按照全局顺序背靠背发生的，在y=1和y=3之间没有来自其他线程的加载或存储。

这是一个实现质量的问题，可以改变实际硬件上观察到的性能/行为。

最明显的问题是进度条。将存储从循环（不包含其他原子操作）中下沉并将它们全部折叠成一个，将导致进度条保持为0，然后在结束时变为100%。

C++11std::atomain没有办法阻止它们在您不需要的情况下执行此操作，所以目前编译器只需选择从不将多个原子操作合并为一个操作。（将它们合并到一个操作中不会改变它们相对于彼此的顺序。）

但是，在某些情况下，它会非常有帮助，例如，避免循环中无用的shared_ptrref count inc/dec。

显然，任何重新排序或合并都不能违反任何其他排序规则。例如，num++；num--；仍然是运行时和编译时重新排序的完全障碍，即使它不再触及num的内存。

目前正在讨论如何扩展std::AtomicAPI，使程序员能够控制这样的优化，这时编译器将能够在有用的时候进行优化，即使是在精心编写的并非故意低效的代码中也可以进行优化。以下工作组讨论/提案链接中提到了一些有益的优化案例：

null

在当前标准中，volatile Atomic y 将是确保不允许对其存储进行优化的一种方法。（正如Herb Sutter在SO回答中指出的那样，volatile和Atomic已经共享了一些需求，但它们是不同的）。另请参见std::memory_order与CPPreference上volatile的关系。

不允许优化对volatile对象的访问（例如，因为它们可能是内存映射的IO寄存器）。

使用volatile atomain 主要解决了进度条问题，但是这有点难看，如果C++决定使用不同的语法来控制优化，那么几年后可能会看起来很傻，这样编译器就可以在实践中开始这样做了。

我认为我们可以相信编译器不会开始进行这种优化，直到有一种方法来控制它。希望它是某种选择（比如memory_order_release_coalesce)，在编译为C++时不会改变现有代码C++11/14代码的行为。但它可能与WG21/P0062中的建议类似：tag don-optimized cases with[[brittle_atomaby]]。

WG21/P0062警告说，即使volatile atomain也不能解决所有问题，并不鼓励将其用于此目的。它给出了这个例子：

if(x) {
    foo();
    y.store(0);
} else {
    bar();
    y.store(0);  // release a lock before a long-running loop
    for() {...} // loop contains no atomics or volatiles
}
// A compiler can merge the stores into a y.store(0) here.

即使使用volatile Atomic y ，也允许编译器将y.store()从if/else中取出，并且只执行一次，因为它仍然使用相同的值执行1个存储。（这将在else分支的长循环之后）。尤其是如果存储区只有replace或release而不是seq_cst。

volatile确实停止了问题中讨论的合并，但这指出了Atomic<>上的其他优化对于实际性能也有问题。

没有优化的其他原因包括：没有人编写复杂的代码来允许编译器安全地进行这些优化（而不会出错）。这是不够的，因为N4455说LLVM已经实现或可以很容易地实现它提到的几个优化。

不过，让程序员困惑的理由当然是合理的。一开始，无锁代码就很难正确地编写。