我想知道为什么没有编译器准备将相同值的连续写入合并到单个原子变量中，例如：
#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);
}
我尝试过的每个编译器都会执行上述写入操作三次。有哪些合法且无竞争的观察者能够看到上述代码与优化版本之间的区别（即 "as-if" 规则不适用）？
如果变量是 volatile 的，则显然不适用任何优化。那么在我的情况下是什么阻止了它？
这是在 编译器探索器 中的代码。
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。依赖于此的程序将有数据竞争错误，但只是普通类型的竞态条件错误，而不是C ++未定义行为类型的数据竞争错误。（仅针对非原子变量才会出现UB）。期望有时看到它的程序不一定有错误。（关于进度条，请参见下文。）y = 1和y = 3之间没有来自其他线程的加载或存储，好像所有三个存储都按照全局顺序依次发生。这是一个实现质量问题，并且可能会改变在真实硬件上观察到的性能/行为。
最明显的问题是进度条。将循环中的存储下沉（不包含其他原子操作）并将它们全部折叠成一个会导致进度条一直停留在0，然后在最后一刻跳到100％。
在没有C++11 std::atomic的情况下，无法阻止编译器在不想要的情况下执行此操作，因此目前编译器选择从不将多个原子操作合并为一个。（将它们全部合并为一个操作不会改变它们相对于彼此的顺序。）
编译器编写者正确地注意到程序员期望每次源代码执行y.store()时都会将原子存储实际发生到内存中。（请参见本问题的大多数其他答案，这些答案声称必须分别执行存储，因为可能有读取器等待看到中间值。）即它违反了最小惊讶原则。
但是，在某些情况下，这将非常有帮助，例如避免在循环中无用的shared_ptr引用计数增加/减少。
显然，任何重新排序或合并都不能违反任何其他排序规则。例如，num++; num--;仍必须是完全屏障以防止运行时和编译时重新排序，即使它不再触及num的内存。
std::atomic API，以使程序员能够控制这些优化。到那时编译器将能够在有用的情况下进行优化，即使是在精心编写但没有故意降低效率的代码中也可能发生。以下工作组讨论/提案链接提到了一些优化的有用案例：volatile atomic<int> y是确保不允许优化存储的一种方法。(正如Herb Sutter在SO答案中指出的那样，volatile和atomic已经共享了一些要求，但它们是不同的)。另请参见cppreference上std::memory_order与volatile的关系。volatile对象的访问不允许被优化掉(因为它们可能是内存映射IO寄存器，例如)。volatile atomic<T>基本上解决了进度条问题，但这有点丑陋，并且如果/当C++决定使用不同的语法来控制优化时，看起来可能很傻。memory_order_release_coalesce)，不会改变现有代码C++11/14编译为C++whatever时的行为。但它可能像wg21/p0062中的提议那样:用[[brittle_atomic]]标记不优化的情况。
wg21/p0062警告即使使用volatile atomic也不能解决所有问题，并且不鼓励将其用于此目的。它给出了以下示例：
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<int> y，编译器仍然可以将y.store()下沉出if/else，只执行一次，因为它仍然以相同的值执行了1次存储。特别是如果存储只是relaxed或release而不是seq_cst。(这将在else分支中的长循环之后执行)。 volatile确实阻止了问题中讨论的合并，但这表明atomic<>上的其他优化对于实际性能也可能存在问题。
对于程序员来说，令人困惑的原因是可信的。无锁代码本来就很难写正确。
在使用原子操作时不要随意浪费：它们不便宜，且目前不会进行优化。然而，使用std::shared_ptr<T>时，往往很难避免冗余的原子操作，因为它没有非原子版本（尽管这里的一个答案给出了一种为gcc定义shared_ptr_unsynchronized<T>的简单方法）。
您在谈论死代码消除。
虽然可以消除原子性的死存储，但是很难证明原子存储是否符合这样的条件。
传统的编译器优化（如死代码消除）可以应用于原子操作，即使是顺序一致的原子操作。
优化器必须小心避免跨越同步点进行此操作，因为另一个执行线程可以观察或修改内存，这意味着传统的优化器在考虑对原子操作进行优化时需要考虑更多的中介指令。
在死代码消除的情况下，仅证明原子存储后支配和别名另一个存储是不足的。
在一般情况下，原子DSE的问题在于需要查找同步点，我理解这个术语指的是代码中存在一个先前发生关系，即指线程A上的一条指令与另一个线程B上的一条指令之间的关系。
考虑下面这段由线程A执行的代码：
y.store(1, std::memory_order_seq_cst);
y.store(2, std::memory_order_seq_cst);
y.store(3, std::memory_order_seq_cst);
能否优化成y.store(3, std::memory_order_seq_cst)？
但如果代码被优化，等待查看y = 2的线程B（例如使用CAS）将永远不会观察到它。
然而，在我看来，B循环并CAS y = 2是数据竞争，因为两个线程之间没有总序。
执行A的指令在B的循环之前执行是可以被观察到（即允许的），因此编译器可以优化为y.store(3, std::memory_order_seq_cst)。
如果线程A和B在线程A的存储操作之间进行同步，则不允许进行优化（可能导致B观察到y = 2）。
证明不存在这样的同步是困难的，因为这涉及考虑更广泛的范围，并考虑架构的所有怪异之处。
据我所知，由于原子操作相对较新且难以推理出内存排序，可见性和同步，编译器在建立更强大的框架以检测和理解必要条件之前不会对原子操作执行所有可能的优化。
我认为你的例子是上面给出的计数线程的简化版本，因为它没有其他线程或任何同步点，据我所见，我认为编译器可能已优化这三个存储操作。
0、1、2等，则另一个线程可能会将某些内容放入由原子指示的插槽中。atomic 中获取当前状态，而工作线程则在没有其他同步的情况下更新了 atomic。该优化将允许编译器仅写一次100％，而不进行冗余写入，这样就可以让进度条显示进度。是否应该允许这种优化存在争议。 - nwpinclude <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);
}
include <atomic>
std::atomic<int> y(0);
void f() {
auto order = std::memory_order_relaxed;
y.store(1, order);
}
但在C++内存模型提供的定义中，它不是数据竞争。
我不能轻易地理解为什么提供了这样的定义，但它确实为开发人员提供了一些方法来在线程之间进行杂乱的通信，他们可能知道（在他们的平台上）会统计工作。
例如，将一个值设置3次然后读取它将显示该位置的某种程度的争用。这些方法并不确定，但许多有效的并发算法并不确定。例如，超时的try_lock_until()总是一种竞争条件，但仍然是一种有用的技术。
似乎C++标准为您提供了关于“数据竞争”的确定性，但允许某些竞争条件的乐趣，这在最终分析中是不同的事情。
简而言之，标准似乎指定其他线程可能看到一个值被设置3次的“锤击”效果的情况下，其他线程必须能够看到该效果（即使它们有时可能不会！）。在几乎所有现代平台上，其他线程在某些情况下可能会看到这种“锤击”效果。
try_lock_for 等东西都会引发竞争！ 为什么编译器不对此进行优化的答案是因为它具有定义明确的语义（可能是有竞争的或其他），而标准希望这些情况发生。 - Persixtyy上旋转并寻找y==2是一种竞争条件（这可能是OP在谈论无竞争观察者时所考虑的）。这只是普通的错误类型的竞争，而不是C++未定义行为类型的竞争。 - Peter Cordes[intro.multithread]的第20段及以下）不允许这样做。y 无关或未修改的重要操作，则可能会：*线程2读取 y 的值以检查线程1的进度。y的值——虽然我没有详细研究过语言标准，但如果它不支持在另一个线程轮询y可能永远看不到值2的硬件，那么我会感到震惊。编译器编写者不能仅仅执行优化。他们还必须确信在编译器编写者打算应用它的情况下，优化是有效的，在不适用的情况下不会被应用，并且不会破坏实际上已经损坏但在其他实现中“工作”的代码。这可能比优化本身更费力。
另一方面，我可以想象，在实践中（也就是在旨在完成工作而不是基准测试的程序中），这种优化将节省很少的执行时间。
因此，编译器编写者将考虑成本，然后考虑收益和风险，并可能决定反对它。
让我们远离三个商店紧挨着的病态案例。假设商店之间有一些非平凡的工作正在进行，而这样的工作根本不涉及y（因此数据路径分析可以确定这三个商店实际上是冗余的，至少在这个线程内），并且不会引入任何内存屏障（以免其他东西强制将商店对其他线程可见）。现在，其他线程很可能有机会在商店之间完成工作，也许这些其他线程操作y，而这个线程有某种原因需要将其重置为1（第二个商店）。如果删除前两个商店，那么行为将发生变化。
由于 std::atomic 对象中包含的变量预计将从多个线程访问，因此应该期望它们至少表现得像使用 volatile 关键字声明的变量。
在 CPU 架构引入缓存行等功能之前，这是标准和推荐做法。
[EDIT2] 有人可能会认为 std::atomic<> 是多核时代的 volatile 变量。根据 C/C++ 的定义，volatile 只足以同步来自单个线程的原子读取，其中 ISR 修改变量（在这种情况下，从主线程看，实际上是原子写入）。
我个人很高兴没有编译器会优化掉对原子变量的写入。如果写入被优化掉了，如何保证其他线程中的读取者可以潜在地看到每个这样的写入呢？不要忘记这也是 std::atomic<> 合同的一部分。
考虑以下代码片段，其结果将受到编译器的疯狂优化的极大影响。
#include <atomic>
#include <thread>
static const int N{ 1000000 };
std::atomic<int> flag{1};
std::atomic<bool> do_run { true };
void write_1()
{
while (do_run.load())
{
flag = 1; flag = 1; flag = 1; flag = 1;
flag = 1; flag = 1; flag = 1; flag = 1;
flag = 1; flag = 1; flag = 1; flag = 1;
flag = 1; flag = 1; flag = 1; flag = 1;
}
}
void write_0()
{
while (do_run.load())
{
flag = -1; flag = -1; flag = -1; flag = -1;
}
}
int main(int argc, char** argv)
{
int counter{};
std::thread t0(&write_0);
std::thread t1(&write_1);
for (int i = 0; i < N; ++i)
{
counter += flag;
std::this_thread::yield();
}
do_run = false;
t0.join();
t1.join();
return counter;
}
[编辑] 起初，我并没有意识到volatile对原子操作的实现是至关重要的，但是...
由于似乎有人怀疑volatile与原子操作是否有关，所以我进行了调查。以下是来自VS2017 STL的原子实现。正如我所推测的那样，volatile关键字被广泛使用。
// from file atomic, line 264...
// TEMPLATE CLASS _Atomic_impl
template<unsigned _Bytes>
struct _Atomic_impl
{ // struct for managing locks around operations on atomic types
typedef _Uint1_t _My_int; // "1 byte" means "no alignment required"
constexpr _Atomic_impl() _NOEXCEPT
: _My_flag(0)
{ // default constructor
}
bool _Is_lock_free() const volatile
{ // operations that use locks are not lock-free
return (false);
}
void _Store(void *_Tgt, const void *_Src, memory_order _Order) volatile
{ // lock and store
_Atomic_copy(&_My_flag, _Bytes, _Tgt, _Src, _Order);
}
void _Load(void *_Tgt, const void *_Src,
memory_order _Order) const volatile
{ // lock and load
_Atomic_copy(&_My_flag, _Bytes, _Tgt, _Src, _Order);
}
void _Exchange(void *_Left, void *_Right, memory_order _Order) volatile
{ // lock and exchange
_Atomic_exchange(&_My_flag, _Bytes, _Left, _Right, _Order);
}
bool _Compare_exchange_weak(
void *_Tgt, void *_Exp, const void *_Value,
memory_order _Order1, memory_order _Order2) volatile
{ // lock and compare/exchange
return (_Atomic_compare_exchange_weak(
&_My_flag, _Bytes, _Tgt, _Exp, _Value, _Order1, _Order2));
}
bool _Compare_exchange_strong(
void *_Tgt, void *_Exp, const void *_Value,
memory_order _Order1, memory_order _Order2) volatile
{ // lock and compare/exchange
return (_Atomic_compare_exchange_strong(
&_My_flag, _Bytes, _Tgt, _Exp, _Value, _Order1, _Order2));
}
private:
mutable _Atomic_flag_t _My_flag;
};
MS stl 中的所有专业都在关键函数上使用 volatile。
以下是其中一个关键函数的声明：
inline int _Atomic_compare_exchange_strong_8(volatile _Uint8_t *_Tgt, _Uint8_t *_Exp, _Uint8_t _Value, memory_order _Order1, memory_order _Order2)
volatile uint8_t*将std::atomic中包含的值保存下来。这种模式可以在MS std::atomic<>实现中观察到，没有任何理由让gcc团队或其他STL提供者以不同的方式进行操作。volatile与不优化内存访问有很大关系，这也是使用原子操作的一个效果。原子操作在此基础上添加了一些非常重要的保证（原子性和排序），但“不要优化掉这个！”的语义适用于两者。 - cmaster - reinstate monicavolatile atomic<int> y 实际上会禁止此优化，因为它意味着存储可能具有副作用。（标准没有提到“IO设备”，但我记得它描述了volatile访问可能具有副作用。） - Peter Cordesvolatile或const volatile：允许这些成员函数在volatile atomic<T>对象上使用。例如，bool _Is_lock_free() const volatile。如果他们不关心volatile atomic，他们根本不会使用volatile关键字。 - Peter Cordes
f只是众多写入y的线程中的一条，而还有其他线程在读取y，那么如果编译器将写操作合并为单个写操作，则程序的行为可能会出现意外变化。 - Some programmer dudey设置为42的C++程序。你可以编写一个仅执行存储操作的程序，也许会有好运气，但无法保证它。不可能确定这种情况从未发生是因为多余的写入被删除了，还是只是由于时间不幸而导致的，因此优化是有效的。即使确实发生了这种情况，你也无法知道是在第一次、第二次还是第三次之前发生的。 - nwp