正如我最近发布的这个答案中所展示的，我似乎对在多线程编程环境下使用volatile的效用（或缺乏效用）感到困惑。
我的理解是：只要一个变量可能在访问它的代码流之外被改变，那么该变量应该声明为volatile。 信号处理程序、I/O寄存器以及被另一个线程修改的变量都构成了这样的情况。
因此，如果你有一个全局的int型变量foo，并且foo被一个线程原子地设置并被另一个线程读取（可能使用适当的机器指令），则读取线程会像看到被信号处理程序调整或被外部硬件条件修改的变量一样看待这种情况，因此foo应该被声明为volatile（或者，在多线程情况下，使用内存屏障加载，这可能是更好的解决方案）。
我在哪里出错了？
volatile存在的问题在于它不能提供我们所需的所有保证。它确实具有我们需要的一些属性，但不是全部，因此我们不能仅依赖volatile。volatile具备的那些属性，因此volatile实际上是不必要的。volatile变量作为标志来指示某些数据是否准备好进行读取。在我们的代码中，我们只需在准备数据之后设置标志，所以一切看起来都很好。但如果指令被重新排序，以致首先设置标志该怎么办？volatile确保第一个点。它还保证不会发生不同的volatile读/写之间的重新排序。所有volatile内存访问将按照指定的顺序发生。这就是我们需要的volatile用于操作I/O寄存器或内存映射硬件的全部内容，但它对于多线程代码并不有帮助。在多线程代码中，volatile对象通常仅用于同步访问非易失性数据，这些访问仍然可以相对于volatile进行重新排序。volatile变量访问周围放置这样的屏障可确保即使非易失性访问也不会在volatile访问之间重新排序，从而允许我们编写线程安全的代码。然而，内存屏障还确保当到达屏障时执行所有待处理的读取/写入操作，因此它本身就能够为我们提供所需的所有内容，使volatile变得不必要。我们可以完全删除volatile限定符。std::atomic<T>）为我们提供了所有相关的保证。volatile为一个完整的内存屏障（防止重新排序）。这不是标准的一部分，因此您不能在可移植代码中依赖于这种行为。 - jalfvolatile对于多线程编程总是无用的。（除了在Visual Studio下，其中volatile 是 内存屏障扩展。） - Nemoglobal_x = 5; extern_call(); cout << global_x; 编译器也不能将其替换为 cout << 5;，因为 extern_call() 可能已更改该值。 - Ben Voigt你也可以考虑从Linux内核文档中了解相关信息。
C程序员通常认为volatile意味着变量可以在当前执行线程之外被更改；因此，当使用共享数据结构时，他们有时会在内核代码中使用它。换句话说，他们已经将易失类型视为一种简单的原子变量，但实际上并非如此。在内核代码中使用volatile几乎从来都是不正确的；本文档描述了其中的原因。volatile也是无意义的。在所有情况下，“调用无法看到其函数体的函数”的行为都是正确的。 - Ben Voigt我认为你没有错 - volatile对于保证线程A看到值的改变是必要的，如果这个值被除了线程A之外的其他东西改变了。据我所知，volatile基本上是一种告诉编译器“不要将这个变量缓存到寄存器中，而是确保每次访问都从RAM内存中读取/写入”的方法。
混淆的原因是volatile对于实现许多事情来说是不够的。特别是，现代系统使用多级缓存，现代多核CPU在运行时进行某些花哨的优化，现代编译器在编译时进行某些花哨的优化，所有这些都可能导致各种副作用以不同的顺序出现，这与您仅查看源代码时期望的顺序不同。
因此，只要记住volatile变量的'观察到'更改可能不会在您认为的精确时间发生，volatile就可以使用。具体而言，请勿尝试使用volatile变量作为在线程间同步或排序操作的方法，因为它不能可靠地工作。
就我个人而言，我对volatile标志的主要（唯一？）用途是作为一个"请立即离开"布尔值。如果我有一个连续循环的工作线程，我会在每次循环迭代时检查volatile布尔值，如果布尔值为true，则退出。然后，主线程可以通过将布尔值设置为true，然后调用pthread_join（）等待工作线程消失来安全地清理工作线程。
SCHED_FIFO，比系统中的其他进程/线程具有更高的静态优先级，并且拥有足够的核心，完全可以实现。在 Linux 中，您可以指定实时进程可使用 100% 的 CPU 时间。如果没有更高优先级的线程/进程，它们将不会发生上下文切换，并且永远不会被 I/O 阻塞。但重点是，C/C++ 的 volatile 并不适用于强制实施正确的数据共享/同步语义。我认为搜索特殊情况来证明错误代码可能有时可以工作是无用的练习。 - FooFvolatile 是实现自旋锁互斥体的基本构造块之一（尽管不足够），但一旦你拥有了它（或更优秀的东西），你就不需要另一个 volatile。
多线程编程的典型方式不是在机器级别保护每个共享变量，而是引入监护变量来指导程序流程。你应该使用 volatile bool my_shared_flag; 而不是这样：
pthread_mutex_t flag_guard_mutex; // contains something volatile
bool my_shared_flag;
这不仅封装了“难点”，而且本质上是必要的：C语言中没有包含实现互斥锁所必需的原子操作；它只有volatile来对普通操作做出额外的保证。
现在你有类似于这样的东西：
pthread_mutex_lock( &flag_guard_mutex );
my_local_state = my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );
pthread_mutex_lock( &flag_guard_mutex ); // may alter my_shared_flag
my_shared_flag = ! my_shared_flag; // critical section
pthread_mutex_unlock( &flag_guard_mutex );
my_shared_flag不需要是volatile的，尽管它是不可缓存的，因为：
&运算符）。
pthread_mutex_lock是一个库函数。pthread_mutex_lock是否以某种方式获取了该引用。pthread_mutex_lock修改了共享标志！volatile是有意义的，但它是多余的。您的理解真的是错误的。
易失性变量具有的属性是“读取和写入该变量是程序可感知行为的一部分”。这意味着该程序可以工作（在适当的硬件条件下）：
int volatile* reg=IO_MAPPED_REGISTER_ADDRESS;
*reg=1; // turn the fuel on
*reg=2; // ignition
*reg=3; // release
int x=*reg; // fire missiles
atomic_t counter;
...
atomic_inc(&counter);
这是原子操作，没有内存屏障。如果需要，您应该添加它们。添加volatile可能不会有帮助，因为它不能将访问与附近的代码相关联（例如，将元素附加到计数器正在计数的列表中）。当然，您不需要在程序外看到计数器增加，优化仍然是可取的。
atomic_inc(&counter);
atomic_inc(&counter);
可以继续优化
atomically {
counter+=2;
}
如果优化器足够聪明（它没有改变代码的语义），
在并发环境中，要使数据一致，需要满足两个条件：
1）原子性，即如果我读取或写入某些数据到内存，则该数据在一次操作中被读取/写入，并且不会由于上下文切换等原因而被打断或争用。
2）一致性，即读/写操作的顺序必须在多个并发环境（线程、机器等）中“看起来”是相同的。
volatile 不符合上述任何一个条件，或者更确切地说，c 或 c++标准中关于 volatile 的行为方式不包括上述任何一个条件。
实际上，情况更糟糕，因为某些编译器（例如英特尔 Itanium 编译器）确实尝试实现某些元素的并发访问安全行为（即通过确保内存屏障），但是编译器实现之间没有一致性，而且标准本身也没有要求实现这一点。
将变量标记为 volatile 只意味着每次都强制将值刷新到内存中，这在许多情况下只会降低代码性能，因为基本上已经破坏了缓存性能。
c# 和 Java 似乎通过使 volatile 遵守 1）和 2）来解决了这个问题，但是对于 c/c++ 编译器来说并非如此，因此您可以根据自己的需要使用它。
有关该主题的更深入（尽管不是无偏见的）讨论，请参阅此处
Butenhof先生在这篇usenet文章中讨论了许多相同的问题：（点击此处查看）：Q56：为什么我不需要声明共享变量为VOLATILE？
然而，我关心的是编译器和线程库都满足各自的规范的情况。符合C规范的编译器可以全局分配一些共享（非volatile）变量到一个寄存器中，并在CPU从一个线程传递到另一个线程时保存并恢复该寄存器。每个线程将拥有自己的私有值，这不是我们从共享变量所期望的。
在某种意义上，如果编译器足够了解变量和pthread_cond_wait（或pthread_mutex_lock）函数的相应作用域，那么这是真实的。事实上，大多数编译器不会尝试跨越调用外部函数保留全局数据的寄存器副本，因为很难知道该例程是否能以某种方式访问数据的地址。
因此，确实，严格（但非常激进）遵守ANSI C的编译器可能不会在没有volatile的情况下与多个线程一起工作。但是必须有人解决这个问题，因为任何未提供POSIX内存一致性保证的系统（实际上，是内核、库和C编译器的组合）都不符合POSIX标准。该系统不能要求您在共享变量上使用volatile以获得正确的行为，因为POSIX仅要求使用POSIX同步函数。
因此，如果您的程序因为没有使用volatile而中断，那么这是一个BUG。它可能不是C中的错误，也可能不是线程库中的错误，也可能不是内核中的错误。但这是一个系统错误，其中一个或多个组件将不得不努力修复它。
您不想使用volatile，因为在任何使其产生差异的系统上，它都比适当的非volatile变量昂贵得多。 （ANSI C要求每个表达式在volatile变量处具有“序列点”，而POSIX仅在同步操作处需要它们 - 计算密集型的线程化应用程序将使用volatile看到更多的内存活动，并且归根结底，真正使您的速度变慢的是内存活动。）
/---[ Dave Butenhof ]-----------------------[ butenhof@zko.dec.com ]---\
| Digital Equipment Corporation 110 Spit Brook Rd ZKO2-3/Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
-----------------[ Better Living Through Concurrency ]----------------/
volatile需要做什么以允许以硬件相关但编译器无关的方式编写操作系统是相当容易的。要求程序员使用实现相关的特性而不是使volatile按照要求工作会削弱制定标准的目的。 - supercat
volatile在读取时创建一个内存屏障，因此它可以用作线程安全标志，表示方法已经结束，因为它强制执行了在设置标志之前的代码与之间的happens-before关系。但在C中不是这种情况。 - Monstieur