(编者按: 在 C + + 11 volatile是不是正确的工具，这项工作仍然有数据竞赛 UB。使用带有 std::memory_order_relaxed加载/存储的 std::atomic<bool>，可以在不使用 UB 的情况下完成此操作。在真正的实现中，它将编译成与 volatile相同的高度。我添加了更多的细节 一个答案，并且还解决了注释中的错误概念，即弱顺序内存可能是这个用例的一个问题: 所有现实世界的 CPU 都有一致的共享内存，所以 volatile将在真正的 C + + 实现中使用 为了这个。但还是不行。

注释中的一些讨论似乎在谈论其他用例，在这些用例中，会需要比轻松的原子更强大的东西。这个答案已经指出，volatile不会给你排序。)

由于以下原因，易失性偶尔是有用的: 这段代码:

/* global */ bool flag = false;


while (!flag) {}

由海湾合作委员会优化，以:

if (!flag) { while (true) {} }

如果标志是由另一个线程写入的，那么这显然是不正确的。请注意，如果没有这种优化，同步机制可能会正常工作(取决于其他代码，可能需要一些内存屏障)——在1生产者-1消费者场景中不需要互斥锁。

否则，volatile 关键字就太奇怪了，无法使用——它不提供任何内存排序，保证 wrt 的易失性访问和非易失性访问，也不提供任何原子操作——也就是说，除了禁用寄存器缓存之外，编译器没有提供任何关于 volatile 关键字的帮助。

简短快速的回答 : volatile对于平台无关的多线程应用程序编程来说(几乎)是无用的。它不提供任何同步，不创建内存隔离，也不确保操作的执行顺序。它不会使操作成为原子操作。它不会神奇地使您的代码成为线程安全的。volatile可能是所有 C + + 中最容易被误解的工具。有关 volatile的更多信息，请参见 这个、 这个和 这个

另一方面，volatile确实有一些不那么明显的用途。它的使用方式与使用 const帮助编译器向您显示在以非保护方式访问某些共享资源时可能出错的地方非常相似。这种用法由 Alexandrescu 在 这篇文章中讨论。然而，这基本上是在使用 C + + 类型系统，通常被视为一种发明，可以唤起未定义行为。

volatile专门用于与内存映射硬件、信号处理程序和 setjmp 机器代码指令接口时。这使得 volatile直接适用于系统级编程，而不是普通的应用程序级编程。

2003年的 C + + 标准并没有说 volatile对变量应用任何类型的获取或发布语义。事实上，标准对多线程的所有问题都保持沉默。但是，特定的平台确实对 volatile变量应用了获取和发布语义。

[ C + + 11更新]

现在的 C + + 11标准 是的在内存模型和语言中直接承认多线程，并且它提供了库设施来以平台无关的方式处理多线程。然而，volatile的语义仍然没有改变。volatile仍然不是同步机制。比雅尼·斯特劳斯特鲁普在《 TCPppl4E:

除非在直接处理的低级代码中，否则不要使用 volatile 用硬件。

不要假设 volatile在内存模型中有特殊意义 不是。它不是——如在一些后来的语言中—— a 要获得同步，请使用 atomic，a mutex或者 condition_variable。

[/更新完毕]

以上这些都适用于 C + + 语言本身，正如2003年的标准(现在是2011年的标准)所定义的那样。然而，一些特定的平台确实给 volatile增加了额外的功能或限制。例如，在 MSVC 2010中(至少)获取和发布语义 做适用于对 volatile变量的某些操作。返回文章页面

优化时，编译器必须维护引用之间的顺序 以及对其他全局对象的引用 特别是,

对易失性对象的写操作(易失性写操作)具有发布语义; 对全局对象或静态对象的引用，该对象在写入 指令序列中的可变对象将在此之前出现 编译后的二进制文件中的可变写入。

易失性对象的读取(易失性读取)具有获取语义; 读取之后发生的全局对象或静态对象的引用 指令序列中的易失性存储器将在那之后发生 已编译二进制文件中的可变读数。

但是，您可能会注意到这样一个事实: 如果您点击上面的链接，那么在评论中会有一些关于是否在这种情况下应用获取/发布语义 事实上的争论。

你需要不稳定的和可能的锁定。

Volatile 告诉优化器值可以异步更改，因此

volatile bool flag = false;


while (!flag) {
/*do something*/
}

将在每次循环中读取标志。

如果您关闭优化或使每个变量易变，程序的行为将相同，但更慢。它的意思是“我知道你可能刚刚读过它，知道它说了什么，但是如果我说读，那就读吧。”。

锁定是程序的一部分。所以，顺便说一下，如果您要实现信号量，那么除了其他事情之外，它们必须是易变的。(不要尝试，这很难，可能需要一个小的汇编程序或新的原子的东西，它已经完成了。)

#include <iostream>
#include <thread>
#include <unistd.h>
using namespace std;


bool checkValue = false;


int main()
{
std::thread writer([&](){
sleep(2);
checkValue = true;
std::cout << "Value of checkValue set to " << checkValue << std::endl;
});


std::thread reader([&](){
while(!checkValue);
});


writer.join();
reader.join();
}

有一次，一个采访者也认为易失性是无用的，他和我争论说，优化不会引起任何问题，而且是指不同的内核有不同的缓存线路，诸如此类(他真的不明白他到底指的是什么)。但是这段代码在 g + + (g + +-O3 thread.cpp-lpthread)上用 -O3编译时，显示了未定义的行为。基本上，如果在 while 检查之前设置了这个值，那么它就可以正常工作，如果不能，那么它就会进入一个循环，而不用费心去获取这个值(实际上这个值已经被另一个线程修改过了)。基本上，我相信 checkValue 的值只被提取到寄存器中一次，并且在最高级别的优化下永远不会被再次检查。如果在提取之前它被设置为 true，那么它就可以正常工作，如果不能正常工作，那么它就进入一个循环。如果我错了，请纠正我。

在 C + + 11中，不要使用 volatile进行线程处理，只用于 MMIO

但是 TL: DR，它的“工作”有点像原子 mo_relaxed在具有相干缓存(即所有内容)的硬件上的工作; 它足以停止编译器在寄存器中保存 vars。atomic不需要内存屏障来创建原子性或线程间可见性，只需要让当前线程在一个操作之前/之后等待，以便在这个线程访问不同变量之间创建顺序。mo_relaxed从来不需要任何障碍，只需要加载，存储，或 RMW。

用于使用 volatile滚动自己的原子(以及用于屏障的内联式原子) 在 C + + 11之前的糟糕的旧时代，volatile是让一些东西工作的唯一好方法。但是，它依赖于许多关于实现如何工作的假设，而且从未得到任何标准的保证。

例如，Linux 内核在 volatile中仍然使用自己的手工原子，但是只支持少数特定的 C 实现(GNU C、 clang，也许还有 ICC)。部分原因是由于 GNU C 扩展和内联提示语法和语义，但也因为它取决于一些关于编译器如何工作的假设。

对于新项目来说，这几乎总是错误的选择; 您可以使用 std::atomic(使用 std::memory_order_relaxed)使编译器发出与使用 volatile相同的高效机器代码。带有 ABC4的 ABC0废弃了用于穿线的 volatile。(可能不包括 在某些编译器上使用 atomic<double>解决缺少优化的错误)

std::atomic在主流编译器上的内部实现(如 gcc 和 clang)只在内部使用 volatile; 编译器直接公开原子加载、存储和 RMW 内置函数。(例如，GNU C __atomic内建操作“普通”对象。)

Volative 在实践中是可用的(但不要这样做)

也就是说，volatile在实践中可用于诸如 all (?)上的 exit_now标志之类的事情实际 CPU 上现有的 C + + 实现，因为 CPU 是如何工作的(一致性缓存) ，以及关于 volatile应该如何工作的共享假设。除此之外就没什么了，这是 没有推荐的。这个答案的目的是解释现有的 CPU 和 C + + 实现实际上是如何工作的。如果您不关心这一点，那么您只需要知道，使用 mo _ rest 的 ABC3在线程方面取代了 volatile。

(ISO C + + 标准对此模糊不清，只是说 volatile访问应该严格按照 C + + 抽象机的规则进行评估，而不是优化掉。假设真正的实现使用机器的内存地址空间来建模 C + + 地址空间，这意味着 volatile读取和分配必须编译为加载/存储指令来访问内存中的对象表示。)

正如另一个答案所指出的，exit_now标志是线程间通信的一个简单例子，它不需要任何同步 : 它不会发布数组内容是否已经准备好或类似的内容。只是一个被另一个线程中未经优化的远程加载及时发现的存储。

    // global
bool exit_now = false;


// in one thread
while (!exit_now) { do_stuff; }


// in another thread, or signal handler in this thread
exit_now = true;

在进入(或不进入)一个无限循环之前，没有可变的或原子的 似是而非的规则和没有数据竞赛的假设 UB 允许编译器优化到只检查一次标志的高度。这正是真正的编译器在现实生活中会发生的情况。(并且通常会优化掉大部分 do_stuff，因为循环永远不会退出，所以如果我们进入循环，任何以后可能使用结果的代码都是不可到达的)。

 // Optimizing compilers transform the loop into asm like this
if (!exit_now) {        // check once before entering loop
while(1) do_stuff;  // infinite loop
}

多线程程序停留在优化模式，但正常运行在-O0 就是一个例子(描述了 GCC 的 asm 输出) ，说明在 x86-64上 GCC 是如何发生这种情况的。SE 上的 单片机编程-C + + O2优化在循环时中断也显示了另一个例子。

我们通常 想要积极的优化，CSE 和提升负载出循环，包括全局变量。

在 C + + 11之前，volatile bool exit_now是按照预期(在正常的 C + + 实现中)实现此功能的一种方式。但是在 C + + 11中，数据竞赛 UB 仍然适用于 volatile，所以它实际上并不是按照 ISO 标准在任何地方工作的 保证，即使假设 HW 相干缓存。