通过访问函数访问共享内存是否需要“易失性”？

Question

[编辑] 对于背景阅读，并且要明确的是，这就是我所说的：易失性关键字简介

在检查嵌入式系统代码时，我看到的最常见错误之一是遗漏了线程/中断共享数据的易失性。然而我的问题是，当通过访问函数或成员函数访问变量时，不使用 volatile 是否“安全”？

一个简单的例子；在下面的代码中......

volatile bool flag = false ;
void ThreadA()
{
    ...
    while (!flag)
    {
        // Wait
    }
    ...
}

interrupt void InterruptB()
{
    flag = true ;
} 

变量 flag 必须是易失性的，以确保 ThreadA 中的读取不会被优化，但是如果通过函数读取该标志

volatile bool flag = false ;
bool ReadFlag() { return flag }
void ThreadA()
{
    ...
    while ( !ReadFlag() )
    {
        // Wait
    }
    ...
}

...... .flag 还需要是易失性的吗？我意识到它是不稳定的并没有什么坏处，但我担心的是它何时被省略并且省略未被发现；这安全吗？

上面的例子很简单；在真实情况下（也是我提出要求的原因），我有一个包装 RTOS 的类库，这样就有一个派生任务对象的抽象类 cTask 。这种“活动”对象通常具有访问数据的成员函数，这些数据可以在对象的任务上下文中修改，但可以从其他上下文访问；那么将此类数据声明为易失性是否至关重要？

我真正感兴趣的是这些数据的保证，而不是实际的编译器可能会做什么。我可能测试了许多编译器，发现它们从未优化通过访问器的读取，但有一天发现一个编译器或编译器设置使这一假设不成立。例如，我可以想象，如果函数是内联的，这样的优化对于编译器来说将是微不足道的，因为它与直接读取没有什么不同。

Answer 1

我对 C99 的理解是，除非您指定 volatile，否则实际访问变量的方式和时间是实现定义的。如果您指定易失性限定符，则代码必须根据抽象机器的规则工作。

标准中的相关部分是：6.7.3 类型限定符（易失性描述）和5.1.2.3 程序执行（抽象机器定义）。

一段时间以来，我知道许多编译器实际上都有启发式方法来检测何时应该再次重新读取变量以及何时可以使用缓存副本。 Volatile 向编译器明确表明，对变量的每次访问实际上都应该是对内存的访问。如果没有 易失性，编译器似乎可以自由地永远不会重新读取该变量。

顺便说一句，将访问包装在函数中并不会改变这一点，因为即使没有内联的函数也可能仍被当前编译单元内的编译器内联。

PS 对于 C++ 可能值得检查前者所基于的 C89。我手头没有C89。

Answer 2

是的，这很关键。
就像您所说的，易失性可防止共享内存上的代码破坏优化[C++98 7.1.5p8]。
由于您永远不知道给定编译器现在或将来可能会执行哪种优化，因此您应该明确指定变量是易失性的。

Answer 3

当然，在第二个示例中，省略了写入/修改变量“flag”。如果它从未被写入，则不需要它是易失性的。

关于主要问题

即使每个线程都通过相同的函数访问/修改该变量，该变量仍然需要被标记为易失性。

一个函数可以在多个线程中同时“活动”。想象一下，函数代码只是一个由线程获取并执行的蓝图。如果线程B 中断线程A 中ReadFlag 的执行，它只是执行ReadFlag 的不同副本（具有不同的上下文，例如不同的堆栈、不同的寄存器内容）。这样做可能会扰乱线程 A 中 ReadFlag 的执行。

Answer 4

在 C 语言中，这里不需要 volatile 关键字（一般意义上）。

来自 ANSI C 规范 (C89)，A8.2 节“类型说明符”：

没有
与实现无关的语义
对于易失性对象。

Kernighan 和 Ritchie对此部分的评论（参考 const< /code> 和 易失性 说明符）：

除了它应该诊断
显式尝试更改 const
对象，编译器可能会忽略这些
预选赛。

鉴于这些详细信息，您无法保证特定编译器如何解释 volatile 关键字，或者它是否完全忽略它。在任何情况下都不应该将完全依赖于实现的关键字视为“必需”。

话虽如此，K&R 还指出：

易失性的目的是强制
抑制的实施
优化，否则可以
发生。

在实践中，这就是我所见过的每个编译器如何解释易失性的方式。将变量声明为易失性，编译器不会尝试以任何方式优化对其的访问。

大多数时候，现代编译器能够很好地判断变量是否可以安全地缓存。如果您发现您的特定编译器正在优化一些不应该优化的内容，那么添加 volatile 关键字可能是合适的。但请注意，这可能会限制编译器对使用 volatile 变量的函数中的其余代码执行的优化量。有些编译器在这方面比其他编译器做得更好；我使用的一个嵌入式 C 编译器会关闭对访问 易失性 的函数的所有优化，但 gcc 等其他编译器似乎仍然能够执行一些有限的优化。

通过访问器函数访问变量应该防止函数缓存该值。即使函数是自动内联的，每次调用该函数都应该重新调用该函数并重新获取新值。我从未见过编译器会自动内联访问器函数，然后优化数据重新获取。我并不是说它不会发生（因为这是依赖于实现的行为），但我不会编写任何期望这种情况发生的代码。您的第二个示例本质上是在变量周围放置一个包装器 API，并且库在不始终使用 易失性 的情况下执行此操作。

总而言之，C 中对易失性对象的处理取决于实现。根据 ANSI C89 规范，它们没有任何“保证”。

您的代码在线程和中断例程之间共享 易失性 对象。没有编译器实现（我见过）能够提供足够的功能来处理并行访问。您应该使用某种锁定机制来保证两个线程（在你的第一个例子）不要踩到对方的脚趾（即使一个是中断处理程序，你仍然可以在多CPU或多核系统上进行并行访问）。

Answer 5

编辑：我没有仔细阅读代码，所以我认为这是一个关于线程同步的问题，永远不应该使用 volatile ，但是这种用法看起来可能没问题（取决于还如何使用有问题的变量，以及中断是否始终运行，使其内存视图与线程看到的内存视图（缓存）一致。 /code> 限定符，如果你将它包装在函数调用中？’接受的答案是正确的，你不能。我将保留我原来的答案，因为对于阅读这个问题的人来说，知道易失性 在某些非常特殊的情况之外几乎没有用。

更多编辑：您的 RTOS 用例可能需要除易失性之外的额外保护，在某些情况下您可能需要使用内存屏障或使它们成为原子......我真的无法告诉当然，这只是你需要小心的事情（我建议查看下面的 Linux 内核文档链接，Linux 不会使用 volatile 来处理此类事情，非常可能有充分的理由）。何时需要或不需要 volatile 在很大程度上取决于您所运行的 CPU 的内存模型，并且通常 volatile 还不够好。

volatile 是执行此操作的错误方法，它不能保证此代码能够工作，它不适合这种用途。

易失性用于读取/写入内存映射设备寄存器，因此它足以达到此目的，但是当您谈论线程之间的内容时它没有帮助。 （特别是编译器仍然大声地重新排序一些读取和写入，就像CPU在执行时一样（这非常重要，因为易失性不会告诉CPU做任何特殊的事情（有时这意味着绕过缓存，但这取决于编译器/CPU））

请参阅 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html，英特尔开发人员文章，CERT, Linux 内核文档

这些文章的简短版本，volatile< /code> 按照您想要的方式使用既不好又错误。不好是因为它会让你的代码变慢，错误是因为它实际上并没有做你想做的事情。

实际上，在 x86 上，无论有或没有易失性，您的代码都可以正常运行，但是它是不可移植的。

编辑：请注意自己实际上阅读了代码...这是 易失性 要做的事情。