为什么 volatile 在多线程 C 或 C++ 编程中没有用？

Question

正如我最近发布的this answer 中所展示的，我似乎对volatile 在多线程编程上下文中的实用性（或缺乏实用性）感到困惑。

我的理解是：任何时候一个变量可能在一段代码访问它的控制流之外被改变，这个变量应该被声明为volatile。信号处理程序、I/O 寄存器以及被另一个线程修改的变量都构成了这种情况。

因此，如果您有一个全局 int foo，并且 foo 由一个线程读取并由另一个线程以原子方式设置（可能使用适当的机器指令），则读取线程以相同的方式看待这种情况看到由信号处理程序调整的变量或由外部硬件条件修改的变量，因此应将foo 声明为volatile（或者，对于多线程情况，使用内存隔离负载访问，这可能是一个更好的解决方案）。

我哪里错了？

Answer 1

您也可以通过Linux Kernel Documentation 考虑这一点。

C 程序员经常认为 volatile 表示变量 可以在当前执行线程之外更改；作为一个 结果，他们有时很想在内核代码中使用它 正在使用共享数据结构。换句话说，他们已经 已知将 volatile 类型视为一种简单的原子变量， 他们不是。在内核代码中使用 volatile 几乎从来没有 正确的;本文档描述了原因。

理解 volatile 的关键在于它的 目的是抑制优化，这几乎从来不是什么 真的很想做。在内核中，必须保护共享数据 针对不需要的并发访问的结构，这在很大程度上是一种 不同的任务。防止不需要的过程 并发也将避免几乎所有与优化相关的问题 以更有效的方式。

像 volatile 一样，内核原语可以同时访问 数据安全（自旋锁、互斥锁、内存屏障等）旨在 防止不必要的优化。如果它们使用得当， 也不需要使用 volatile 。如果 volatile 仍然 必要时，几乎可以肯定代码中的某个地方存在错误。在 正确编写的内核代码，易失性只能用于减慢速度 下来。

考虑一个典型的内核代码块：

spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

如果所有代码都遵循锁定规则，shared_data的值 持有 the_lock 时不能意外更改。任何其他代码 可能想要使用该数据的将在锁上等待。 自旋锁原语充当内存屏障——它们是显式的 这样做 - 意味着数据访问不会被优化 穿过他们。所以编译器可能会认为它知道里面会有什么 shared_data，但 spin_lock() 调用，因为它充当内存 障碍，会迫使它忘记它所知道的一切。将没有 访问该数据的优化问题。

如果 shared_data 被声明为 volatile，锁定仍然是 必要的。但是编译器也会被阻止优化 当我们知道 没有其他人可以使用它。在持有锁的同时， shared_data 不是易失的。在处理共享数据时，适当 锁定使 volatile 变得不必要 - 并且可能有害。

易失性存储类最初用于内存映射 I/O 寄存器。在内核中，寄存器访问也应该是 受锁保护，但也不希望编译器 “优化”关键部分中的寄存器访问。但是，内 内核，I/O 内存访问总是通过访问器完成 职能;直接通过指针访问 I/O 内存被皱眉 在所有架构上并且不适用于所有架构。这些访问器是 为防止不必要的优化而编写，因此，volatile 是 没必要。

另一种可能会尝试使用 volatile 的情况是 处理器正忙于等待变量的值。正确的 执行忙碌等待的方法是：

while (my_variable != what_i_want)
    cpu_relax();

cpu_relax() 调用可以降低 CPU 功耗或屈服于 超线程双处理器；它也恰好作为记忆 障碍，所以，再一次， volatile 是不必要的。当然， 忙着等待通常是一种反社会行为。

仍有一些罕见的情况下 volatile 在 内核：

• 上述访问器函数可能使用 volatile on 直接 I/O 内存访问确实有效的架构。本质上， 每个访问器调用本身都成为一个小的关键部分，并且 确保访问按程序员的预期进行。

• 内联汇编代码改变内存，但没有其他 可见的副作用，有被 GCC 删除的风险。添加挥发物 asm 语句的关键字将阻止此删除。

• jiffies 变量的特殊之处在于它可以有不同的值 每次都被引用，但是没有什么特别的就可以读取 锁定。所以 jiffies 可能是不稳定的，但是添加其他 这种类型的变量被强烈反对。 Jiffies 被认为是 在这方面成为一个“愚蠢的遗产”问题（Linus 的话）；修复它 麻烦多于其价值。

• 指向可能被修改的相干内存中的数据结构的指针 有时，通过 I/O 设备可以合法地波动。环形缓冲区 由网络适配器使用，该适配器将指针更改为 指示哪些描述符已被处理，就是一个例子 情况类型。

对于大多数代码，以上对 volatile 的理由都不适用。 因此，使用 volatile 很可能被视为一个错误，并且 将对代码进行额外的审查。开发人员 想使用 volatile 应该退后一步，想想什么 他们真的在努力完成。

Answer 2

comp.programming.threads 常见问题解答有 a classic explanation，作者是 Dave Butenhof：

Q56：为什么我不需要声明共享变量VOLATILE？

但是，我担心编译器和 线程库满足各自的规范。一个符合的 C 编译器可以全局分配一些共享（非易失）变量到 当 CPU 从 线程到线程。每个线程都有自己的私有值 这个共享变量，这不是我们想要的共享变量 变量。

在某种意义上这是真的，如果编译器对 变量和 pthread_cond_wait 的各自范围（或 pthread_mutex_lock) 函数。在实践中，大多数编译器不会尝试 在对外部的调用中保留全局数据的寄存器副本 函数，因为很难知道例程是否可能 以某种方式可以访问数据的地址。

所以是的，严格遵守的编译器确实如此（但非常 积极地）到 ANSI C 可能无法在没有多个线程的情况下工作 易挥发的。但最好有人修复它。因为任何系统（即， 务实地，内核、库和 C 编译器的组合） 不提供 POSIX 内存一致性保证 不符合 POSIX 标准。时期。系统不能要求您使用 volatile 在共享变量上以确保正确的行为，因为 POSIX 只要求 POSIX 同步函数是必需的。

因此，如果您的程序因未使用 volatile 而中断，那就是 BUG。 它可能不是 C 中的错误，也可能不是线程库中的错误，也可能不是 内核。但这是一个系统错误，以及其中一个或多个组件 必须努力修复它。

您不想使用 volatile，因为在它生成的任何系统上 任何区别，它都会比适当的贵得多 非易失性变量。 （ANSI C 需要 volatile 的“序列点” 每个表达式的变量，而 POSIX 仅在 同步操作——计算密集型线程应用程序 使用 volatile 会看到更多的内存活动，并且，之后 总而言之，真正让你慢下来的是记忆活动。）

/---[戴夫布滕霍夫]-----------------------[butenhof@zko.dec.com]---\
| Digital Equipment Corporation 110 Spit Brook Rd ZKO2-3/Q18 |
| 603.881.2218, 传真 603.881.0120 纳舒厄 NH 03062-2698 |
-----------------[通过并发改善生活]----------------/

Butenhof 先生在this usenet post 中涵盖了许多相同的领域：

使用“易失性”不足以确保正确的内存 线程之间的可见性或同步。互斥锁的使用是 足够了，而且，除非借助各种非便携式机器 代码替代品，（或更微妙的 POSIX 内存含义 更难以普遍应用的规则，如在 我以前的帖子），互斥锁是必需的。

因此，正如 Bryan 所解释的，使用 volatile 可以完成 只不过是为了防止编译器变得有用和可取 优化，在使代码“线程”方面没有任何帮助 安全”。当然，欢迎您将任何您想要的东西声明为 “volatile”——毕竟这是一个合法的 ANSI C 存储属性。只是 不要指望它能为你解决任何线程同步问题。

所有这些都同样适用于 C++。

Answer 3

volatile 在多线程上下文中的问题在于它没有提供所有我们需要的保证。它确实有一些我们需要的属性，但不是全部，所以我们不能依赖volatile单独。

但是，我们必须为 剩余 属性使用的原语也提供了 volatile 所做的那些，因此实际上没有必要。

对于共享数据的线程安全访问，我们需要保证：

• 实际上发生了读/写（编译器不会只将值存储在寄存器中，而是将更新主内存推迟到很久以后）
• 不会发生重新排序。假设我们使用volatile 变量作为标志来指示某些数据是否准备好被读取。在我们的代码中，我们只是在准备好数据后设置了标志，所以所有看起来都很好。但是如果指令被重新排序以设置标志first呢？

volatile 确实保证了第一点。它还保证在不同的易失性读/写之间不会发生重新排序。所有volatile 内存访问都将按照它们指定的顺序发生。这就是 volatile 的用途所需要的全部内容：操作 I/O 寄存器或内存映射硬件，但在 volatile 对象通常仅用于同步访问非- 易失性数据。这些访问仍然可以相对于volatile 重新排序。

防止重新排序的解决方案是使用内存屏障，它向编译器和 CPU 都表明内存访问不能在此点重新排序。在我们的 volatile 变量访问周围放置这样的障碍可确保即使是非 volatile 访问也不会在 volatile 中重新排序，从而允许我们编写线程安全的代码。

但是，内存屏障也确保在达到屏障时执行所有挂起的读/写操作，因此它有效地为我们提供了我们需要的一切，从而使volatile 变得不必要。我们可以完全删除 volatile 限定符。

自 C++11 起，原子变量 (std::atomic<T>) 为我们提供了所有相关保证。

Answer 4

根据我的旧 C 标准，“构成对具有 volatile 限定类型的对象的访问是实现定义的”。因此，C 编译器编写者可以选择“volatile”表示“多进程环境中的线程安全访问”。但他们没有。

相反，在多核多进程共享内存环境中使临界区线程安全所需的操作被添加为新的实现定义的功能。而且，由于摆脱了“易失性”将在多进程环境中提供原子访问和访问顺序的要求，编译器编写者优先考虑代码缩减而不是依赖于历史实现的“易失性”语义。

这意味着关键代码部分周围的“易失性”信号量之类的东西，在新硬件和新编译器上不起作用，可能曾经在旧硬件上与旧编译器一起工作，而且旧示例有时并没有错，只是旧的。

Answer 5

这就是“volatile”所做的一切： “嘿编译器，即使没有本地指令作用于它，这个变量也可能在任何时刻（在任何时钟滴答）发生变化。不要将此值缓存在寄存器中。”

那就是 IT。它告诉编译器你的值是易变的——这个值可能随时被外部逻辑（另一个线程、另一个进程、内核等）改变。它的存在或多或少只是为了抑制编译器优化，这些优化将在寄存器中静默缓存一个值，它对 EVER 缓存本质上是不安全的。

您可能会遇到诸如“Dr. Dobbs”之类的文章，它们将 volatile 视为多线程编程的灵丹妙药。他的方法并非完全没有优点，但它的根本缺陷是让对象的用户对其线程安全负责，这往往与其他违反封装的问题相同。

Answer 6

为了使您的数据在并发环境中保持一致，您需要应用两个条件：

1) 原子性，即如果我在内存中读取或写入一些数据，那么这些数据会一次性读取/写入，并且不能因上下文切换而被中断或竞争

2) 一致性，即读/写操作的顺序必须可见在多个并发环境之间是相同的 - 无论是线程、机器等

volatile 不符合上述任何一项——或者更具体地说，关于 volatile 应如何表现的 c 或 c++ 标准不包括上述任何一项。

在实践中甚至更糟，因为某些编译器（例如 intel Itanium 编译器）确实尝试实现并发访问安全行为的某些元素（即通过确保内存围栏）但是编译器实现之间没有一致性，而且标准确实如此首先不需要这个实现。

将变量标记为 volatile 仅意味着您每次都强制将值刷新到内存中或从内存中刷新，这在许多情况下只会减慢您的代码速度，因为您基本上已经破坏了缓存性能。

c# 和 java AFAIK 确实通过使 volatile 遵守 1) 和 2) 来解决这个问题，但是对于 c/c++ 编译器不能这样说，所以基本上按照你认为合适的方式处理它。

有关该主题的更深入（尽管并非公正）讨论，请阅读this

Answer 7

volatile 对于实现自旋锁互斥锁的基本构造很有用（尽管不够），但是一旦你拥有了它（或更好的东西），你就不需要另一个 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 不需要是易失性的，尽管不可缓存，因为

1. 另一个线程可以访问它。
2. 表示对它的引用一定是在某个时候被引用的（使用& 运算符）。
   • （或引用包含结构）
3. pthread_mutex_lock 是一个库函数。
4. 意味着编译器无法判断 pthread_mutex_lock 是否以某种方式获取了该引用。
5. 意味着编译器必须假定 pthread_mutex_lock 修改了共享标志！
6. 因此必须从内存中重新加载变量。 volatile 虽然在这种情况下很有意义，但却是无关紧要的。

Answer 8

你的理解真的错了。

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

问题是，这不是我们想要的线程安全属性。

例如，一个线程安全的计数器就是（linux-kernel-like 代码，不知道 c++0x 的等价物）：

atomic_t counter;

...
atomic_inc(&counter);

这是原子的，没有内存屏障。如有必要，您应该添加它们。添加 volatile 可能无济于事，因为它不会关联对附近代码的访问（例如，将元素附加到计数器正在计数的列表中）。当然，您不需要在程序之外看到计数器递增，并且仍然需要优化，例如。

atomic_inc(&counter);
atomic_inc(&counter);

仍可优化为

atomically {
  counter+=2;
}

如果优化器足够聪明（它不会改变代码的语义）。

Answer 9

我不认为你错了—— volatile 是必要的，以保证线程 A 会看到值的变化，如果值被线程 A 以外的东西改变。据我了解， volatile 基本上是一种方式告诉编译器“不要将此变量缓存在寄存器中，而是确保在每次访问时始终从 RAM 内存中读取/写入它”。

混淆是因为 volatile 不足以实现许多事情。特别是现代系统使用多级缓存，现代多核 CPU 在运行时进行一些花哨的优化，现代编译器在编译时进行一些花哨的优化，这些都可能导致各种副作用以不同的方式出现。如果您只是查看源代码，请按照您期望的顺序进行排序。

所以 volatile 没问题，只要您记住 volatile 变量中的“观察到的”变化可能不会在您认为它们会发生的确切时间发生。具体来说，不要尝试使用 volatile 变量作为跨线程同步或排序操作的一种方式，因为它不会可靠地工作。

就个人而言，我对 volatile 标志的主要（唯一？）用途是作为“pleaseGoAwayNow”布尔值。如果我有一个连续循环的工作线程，我将让它在循环的每次迭代中检查 volatile 布尔值，如果布尔值为真则退出。然后主线程可以通过将布尔值设置为 true 来安全地清理工作线程，然后调用 pthread_join() 等待工作线程消失。