编译器在处理易失性内存位置时必须遵循哪些规则？

Question

我知道当从由多个线程或进程写入的内存位置读取时，应该在该位置使用 volatile 关键字，如下例所示，但我想更多地了解它到底有哪些限制make for 编译器，基本上编译器在处理这种情况时必须遵循哪些规则，以及是否存在任何例外情况，尽管同时访问内存位置，但程序员可以忽略 volatile 关键字。

volatile SomeType * ptr = someAddress;
void someFunc(volatile const SomeType & input){
 //function body
}

Answer 1

你所知道的都是假的。易失性不用于同步线程之间的内存访问、应用任何类型的内存栅栏或任何此类内容。对易失性内存的操作不是原子的，并且不保证它们按任何特定顺序进行。 易失性是整个语言中最容易被误解的工具之一。 “易失性对于多线程编程来说几乎没用。”

易失性的用途是与内存映射硬件、信号处理程序和setjmp机器代码指令进行交互。

它的使用方式也可以与 const 类似，这就是 Alexandrescu 在

编辑：我将尝试详细说明我刚才所说的内容。

假设您有一个类，它有一个指向无法更改的内容的指针。您自然可以将指针设置为 const：

class MyGizmo
{ 
public:
  const Foo* foo_;
};

const 在这里真正为您做什么？它对记忆没有任何作用。它不像旧软盘上的写保护标签。内存本身仍然可写。您只是无法通过 foo_ 指针对其进行写入。所以 const 实际上只是给编译器提供另一种方式让你知道你什么时候可能搞砸了的一种方式。如果您要编写以下代码：

gizmo.foo_->bar_ = 42;

...编译器将不允许这样做，因为它被标记为 const。显然，您可以通过使用 const_cast 抛弃 const 来解决这个问题，但如果您需要确信这是一个坏主意，那么对您没有任何帮助。 :)

Alexandrescu 对 volatile 的使用是完全相同的。它不会做任何事情来使内存在某种程度上“线程安全”以任何方式。它的作用是为编译器提供另一种方式让您知道何时可能搞砸了。您将真正“线程安全”的事物（通过使用实际的同步对象，如互斥体或信号量）标记为易失性。那么编译器将不允许您在非易失性上下文中使用它们。它会抛出一个编译器错误，然后您必须考虑并修复。您可以再次通过使用 const_cast 抛弃 volatile-ness 来绕过它，但这与抛弃 const-ness 一样邪恶。

我对您的建议是完全放弃 volatile 作为编写多线程应用程序的工具（编辑：），直到您真正知道自己在做什么以及为什么这样做。它有一些好处，但并不像大多数人想象的那样，如果你使用不当，你可能会编写出危险的不安全应用程序。

Answer 2

在 C++11 及更高版本中，没有理由将 volatile 用作穷人的 std::atomic 和 std::memory_order_relaxed。只需将 std::atomic 与 relaxed 结合使用即可。在 volatile 按照您想要的方式工作的编译器上，带有 relaxed 的 std::atomic 将编译成大约相同的 asm，速度同样快。请参阅 何时将 volatile 与多线程一起使用？（从不）

这个答案关于一个单独的问题，即易失性的规则到底是什么。

---

它的定义并不像您希望的那样明确。 C++98 中的大多数相关标准都在第 1.9 节“程序执行”中：

抽象机的可观察行为是其对易失性数据的读取和写入以及对库I/O函数的调用的序列。

访问由易失性左值（3.10）指定的对象、修改对象、调用库 I/O 函数或调用执行任何这些操作的函数都是端效果，即执行环境状态的变化。表达式的求值可能会产生副作用。在执行序列中称为序列点的某些指定点，先前评估的所有副作用都应完成，并且后续评估的副作用不会发生。

一旦函数开始执行，在被调用函数执行完成之前，不会计算调用函数中的表达式。

当抽象机的处理因接收到信号而中断时，除 易失性 sig_atomic_t 类型以外的对象的值是未指定的，并且任何非 易失性的对象的值由处理程序修改的 sig_atomic_t 变为未定义。

每个具有自动存储持续时间（3.7.2）的对象的实例与其块中的每个条目相关联。这样的对象存在并在块执行期间和块挂起（通过调用函数或接收信号）期间保留其最后存储的值。

符合实施的最低要求是：

• 在序列点，易失性对象是稳定的，因为先前的评估已完成且后续评估尚未发生。

• 在程序终止时，写入文件的所有数据应与根据抽象语义执行程序可能产生的结果之一相同。

• 交互设备的输入和输出动态应以提示消息实际出现在程序等待输入之前的方式发生。交互设备的构成是由实现定义的。

所以归结起来就是：

• 编译器无法优化对易失性对象的读取或写入。对于像卡萨布兰卡提到的那样的简单情况，这可能会像您想象的那样工作。然而，在类似的情况下

   易失性 int a;
    整数b；
    b = a = 42;
  

  人们可以而且确实争论编译器是否必须像最后一行已读取一样生成代码

  <前><代码> a = 42; b = a；

  或者如果它可以，像通常一样（在没有易失性的情况下），生成

  <前><代码> a = 42; b = 42；

  （C++0x 可能已经解决了这一点，我还没有阅读全文。）

• 编译器可能不会对发生在单独语句（每个分号是一个序列点），但完全允许相对于易失性对象重新安排对非易失性对象的访问。这是您不应尝试编写自己的自旋锁的众多原因之一，也是 John Dibling 警告您不要将 易失性 视为多线程编程的灵丹妙药的主要原因。

• 说到线程，您会注意到标准文本中完全没有提及任何线程。这是因为C++98没有线程的概念。 （C++0x 确实如此，并且很可能指定它们与 volatile 的交互，但如果我是你，我不会假设任何人都实现了这些规则。）因此，没有< /em> 保证从一个线程对易失性对象的访问对于另一个线程是可见的。这是 易失性 对于多线程编程不是特别有用的另一个主要原因。

  
  

• 无法保证 易失性 对象被整体访问，或者对 易失性 对象的修改避免触及内存中紧邻它们的其他内容。这在我引用的内容中并不明确，但由有关 volatile sig_atomic_t 的内容暗示 - 否则 sig_atomic_t 部分将是不必要的。这使得易失性对于访问I/O设备的用处大大低于其预期，并且用于嵌入式编程的编译器通常提供更强的保证，但这不是您可以指望的。 p>

• 很多人尝试对具有易失性语义的对象进行特定访问，例如执行

  <前><代码> T x;
  *(易失性T *)&x = foo();

  这是合法的（因为它说“对象由易失性左值指定”，而不是“对象具有易失性类型”），但必须非常小心地完成，因为还记得我说过编译器完全允许相对于易失性访问重新排序非易失性访问吗？ 即使是同一个对象也是如此（据我所知）。

• 如果您担心对多个易失性值的访问在编译时重新排序，您需要了解序列点规则，该规则又长又复杂，并且我不会在这里引用它们，因为这个答案已经太长了，但是 这是一个很好的解释，只是稍微简化了。如果您发现自己需要担心 C 和 C++ 之间序列点规则的差异，那么您已经在某个地方搞砸了（例如，根据经验，永远不要重载 &&）。

  如果您还需要对 易失性 存储的可见性进行运行时排序（如 x86 以外的 ISA 上其他线程中的 易失性 加载所见），则需要内联asm 或屏障指令的内在函数...或者更好的是，将 std::atomic 与除 relaxed 以外的内存顺序一起使用，例如 std::memory_order_acquire > 和 std::memory_order_release。 （这些排序在 x86 上仍然是“免费”的，但将在具有弱排序内存模型的非 x86 上使用特殊的加载/存储指令或屏障。）

  std::atomic 还具有能够在线程之间建立发生前同步的巨大优势，例如可以释放存储 data_ready 标志，以便读者可以获取加载，然后（如果标志为真）访问普通数组。 （MSVC 历史上提供了易失性获取和释放语义 所以它可以执行此操作，/volatile:ms 启用此行为，/volatile:iso 禁用该额外排序。）

Answer 3

易失性排除的一个特殊且非常常见的优化是将内存中的值缓存到寄存器中，并使用寄存器进行重复访问（因为这比每次都返回内存要快得多） ）。

相反，编译器每次都必须从内存中获取值（根据 Zach 的提示，我应该说“每次”都受到序列点的限制）。

写入序列也不能使用寄存器，并且只能稍后将最终值写回：每次写入都必须被推送到内存。

为什么这有用？在某些架构上，某些 IO 设备将其输入或输出映射到内存位置（即写入该位置的字节实际上在串行线上输出）。如果编译器将其中一些写入重定向到仅偶尔刷新的寄存器，则大多数字节不会进入串行线路。不好。使用易失性可以防止这种情况。

Answer 4

将变量声明为易失性意味着编译器无法对它本来可以做的值做出任何假设，从而阻止编译器应用各种优化。本质上，它强制编译器在每次访问时重新从内存中读取值，即使正常的代码流不会更改该值。例如：

int *i = ...;
cout << *i; // line A
// ... (some code that doesn't use i)
cout << *i; // line B

在这种情况下，编译器通常会假设由于 i 处的值在中间没有被修改，因此可以保留 A 行的值（比如在寄存器中）并打印B 中的值相同。但是，如果将 i 标记为 易失性，则告诉编译器某些外部源可能修改了 i< 处的值/code> 位于 A 行和 B 行之间，因此编译器必须从内存中重新获取当前值。

Answer 5

不允许编译器优化循环中对易失性对象的读取，否则它通常会这样做（即 strlen()）。

它通常在嵌入式编程中用于读取固定地址处的硬件注册表，并且该值可能会意外更改。 （与“正常”内存相反，除非由程序本身写入，否则它不会改变......）

这就是它的主要目的。

它还可用于确保一个线程看到另一个线程写入的值的变化，但它绝不能保证读/写所述对象时的原子性。