3
“ volatile”对于多核系统的可移植C代码是否有任何保证？
看着经过一大堆 的 其他 问题 和 他们的 答案，我得到的印象是有什么在C“挥发性”关键字表示正好没有广泛的协议。 即使标准本身似乎也不够清晰，每个人都无法理解其含义。 除其他问题外： 根据您的硬件和编译器，它似乎提供了不同的保证。 它影响编译器优化，但不影响硬件优化，因此在执行自己的运行时优化的高级处理器上，甚至不清楚编译器是否可以阻止您要阻止的任何优化。（某些编译器确实会生成指令来阻止某些系统上的某些硬件优化，但这似乎并未以任何方式进行标准化。） 总结一下问题，似乎（经过大量阅读）“ volatile”保证了类似的结果：该值将不但从/向寄存器，而且至少向内核的L1缓存中读/写，其顺序与读/写出现在代码中。但这似乎没有用，因为在同一个线程中读/写寄存器已经足够，而与L1缓存协调并不能保证与其他线程的协调。我无法想象仅与L1缓存进行同步的重要性。 用途1 唯一广泛同意使用volatile的似乎是旧的或嵌入式系统，其中某些内存位置通过硬件映射到I / O功能，例如内存中的某个位（直接在硬件中）控制灯光。 ，或告诉您键盘按键是否按下的内存中的某个位（因为它是通过硬件直接连接到按键的）。 看来，“用1”不移植的代码，其目标包括多核系统发生。 USE 2 与“ use 1”没什么不同，它是可由中断处理程序（可以控制灯光或从键存储信息）随时读取或写入的内存。但是为此已经存在一个问题，即取决于系统，中断处理程序可能会在 具有自己的内存缓存的不同内核上运行，并且“ volatile”不能保证所有系统上的缓存一致性。 因此，“使用2”似乎超出了“易失性”所能提供的范围。 用途3 我看到的唯一其他无可争议的用途是防止通过不同变量指向指向编译器未意识到的相同内存的不同内存的访问优化。但这可能只是无可争议的，因为人们没有在谈论它-我只看到其中一个提及。而且我认为C标准已经认识到“不同”的指针（例如指向函数的不同args）可能指向同一项目或附近的项目，并且已经指定编译器必须生成即使在这种情况下也可以工作的代码。但是，我无法在最新的标准（500页！）中快速找到此主题。 那么“使用3”也许根本不存在？ 因此，我的问题是： 在多核系统的可移植C代码中，“ volatile”是否完全可以保证？ 编辑-更新 浏览最新标准后，答案似乎至少是非常有限的： 1.标准针对特定类型“ volatile sig_atomic_t”反复指定特殊处理。但是该标准还说，在多线程程序中使用信号功能会导致不确定的行为。因此，该用例似乎仅限于单线程程序与其信号处理程序之间的通信。 2.该标准还为setjmp / longjmp指定了“ volatile”的明确含义。（在其他问题和答案中给出了重要示例代码）。 因此，更精确的问题变成了： 除了（1）允许单线程程序从其信号处理程序接收信息之外，还是（2）允许setjmp，“ volatile”是否可以保证多核系统的可移植C代码中的任何内容？代码以查看在setjmp和longjmp之间修改的变量？ 这仍然是一个是/否问题。 如果为“是”，那么最好显示一个无错误的可移植代码示例，如果省略了“ volatile”，则该示例会出现错误。如果为“ no”，那么我认为对于多核目标，在这两种非常特殊的情况下，编译器可以随意忽略“ volatile”。