C++具有由函数访问的全局共享变量的 volatile 关键字

Question

我有一个多线程 C++ 应用程序。

现在我知道，对于全局共享变量，在某些情况下应该在检查变量的状态时使用 volatile，否则编译器可能会假设变量的值永远不会改变（在该线程中）。

但是，如果我调用返回变量值的方法而不是检查变量的状态，该怎么办？例如：

static int num = 0;

...

void foo()
{
   while(getNum() == 0)
   {
      // do something (or nothing)
   }
}

我还需要将 num 设为 volatile 变量吗？或者编译器是否认识到，由于我正在使用一种方法来访问该变量 num，因此它不会缓存结果？

有人有什么想法吗？

提前致谢，

〜Julian

编辑：在我的 while 循环中，我删除了 sleep 调用，并将其替换为通用的内容，例如执行某事（或不执行任何操作）的注释

Answer 1

不，只要您进行必要的同步，就永远不需要易失性。

调用线程库同步函数，无论它们在您的平台上是什么，都应该注意使本地“缓存”值无效并使编译器重新加载全局变量。

在这种特殊情况下，sleep 很可能会产生这样的效果，但无论如何它都不是一个好的实现。 num 上应该有一个条件变量，用 setter 函数保护它，并让 setter 函数向 foo 发送信号。

至于具体问题，函数是否隐藏优化的访问是极其依赖于实现和情况的。最好的选择是在编译器的单独调用中编译 getter 函数，但即使如此，也无法保证不会发生过程间优化。例如，某些平台可能会将 IR 代码放入 .o 文件中，并在“链接器”阶段执行代码生成。

免责声明。

上面的关键词：1.只要你做了必要的同步和2.可能有这样的效果。

1：睡眠或空的忙循环不是“必要的同步”。这不是编写多线程程序的正确方法。因此，在这种情况下可能需要 volatility。

2：是的，sleep 可能不会被 I/O 函数的实现计算在内，甚至可能被标记为纯粹且无副作用。在这种情况下，全局的易失性是必要的。然而，我怀疑是否真的有任何分布式实现会破坏这样的睡眠循环，因为不幸的是它们很常见。

Answer 2

您提出的基本上是对“易失性”的滥用，其真正目的是告诉编译器该变量可能会被外部硬件或系统中的其他进程修改，因此，每次使用时都需要从内存中读取它。

它不会保护您免受程序中的线程冲突等影响，尽管在您的情况下，您似乎正在使用该标志来发出关闭请求信号。

如果您知道只有一个控制线程会更新变量，那么在不进行同步等的情况下执行此操作实际上是可以的。另外，我会使用位操作来设置标志，因为这在更多硬件上更有可能是“原子的”。

num && x'00000001' 

Answer 3

不幸的是，易失性语义有点软弱。易失性的概念并不是真正用于线程。

Potatoswatter 是正确的，调用操作系统同步原语通常会阻止优化编译器从循环中提升 num 的读取。但它的工作原理与使用访问器方法的工作原理相同......偶然。

编译器看到您调用的函数不能立即用于内联或分析，因此它必须假设可以由其他函数使用的任何变量都可以在该不透明函数中读取或更改。因此，在进行调用之前，编译器需要将所有这些“全局”变量写回内存。

在 corensic，我们向 jinx.h 添加了一个内联函数，以更直接的方式执行此操作。如下所示：

 inline void memory_barrier() { asm volatile("nop" ::: "memory"); }

这是相当微妙的，但它有效地告诉编译器（gcc）它无法摆脱这块不透明asm，并且不透明asm可以读取或写入任何全局可见的内存块。这有效地阻止了编译器跨此边界重新排序加载/存储。

对于您的示例：

memory_barrier();
而（数字== 0）{
内存_屏障（）；
...
现在

num 的读取被卡在原地。更重要的是，它与其他代码的关系固定不变。所以你可以：

 while (flag == 0) { memory_barrier(); }  // spin
 process data[0..N]

而另一个线程则可以：

 populate data[0..N]
 memory_barrier();
 flag = 1;

PS。如果您执行此类操作（本质上是创建您自己的同步原语），性能优势可能很大，但质量风险很高。 Jinx 特别擅长发现这些无锁结构中的错误。因此，您可能想使用它或其他一些工具来帮助测试这些东西。

聚苯硫醚。 Linux 社区有一篇关于此问题的很好的帖子，名为“挥发性被认为是有害的”，请查看。

Answer 4

从技术上讲，它确实需要被标记为易失性的。只要代码继续符合 C++ 抽象机规范，编译器就可以自由地做他们想做的事情来优化代码。具有足够资源的符合标准的编译器可以在程序的整个生命周期内内联 getNum 的所有实例，将 num 的值移动到寄存器中（或者简单地注意到它从未被任何代码实际更改，将其视为常量） 。

实际上，（当前）CPU 没有足够的可用寄存器，即使是最积极的优化编译器也会选择这样做。但如果需要正确性，则需要 volatility。