C volatile，以及硬件缓存问题

Question

我已经在本网站和其他地方阅读过类似的答案，但在某些情况下仍然感到困惑。

我知道标准实际上向我们保证了什么，我理解关键字的预期用途，并且我很清楚编译器缓存和 L1/L2/ect 之间的区别。缓存；我了解其他情况更多是出于好奇。

假设我有一个在 C 中声明为 volatile 的变量。四种情况:

1. 信号处理程序，单线程(按预期):这就是关键字旨在解决的问题。我的进程从操作系统获取信号回调，然后我在进程的正常执行之外修改了一些 volatile 变量。因为它被声明为 volatile，所以正常进程不会将此值存储在 CPU 寄存器中，而是始终从内存中加载。即使信号处理程序写入 volatile 变量，由于信号处理程序与正常进程共享相同的地址空间，即使 volatile 变量先前已缓存 在硬件中(即 L1、L2)，我们保证主进程将加载正确的、更新的变量。完美，大家都很开心。
2. DMA 传输，单线程:假设 volatile 变量映射到内存区域，该区域正在执行 DMA 写入。和以前一样，编译器不会将 volatile 变量保存在 CPU 寄存器中，而是始终从内存中加载；但是，如果该变量存在于硬件 缓存中，那么加载请求将永远不会到达主内存。如果 DMA Controller 在我们背后更新 MM，我们将永远无法获得最新值。在抢占式操作系统中，我们最终可能会被上下文切换，并且下次我们的进程恢复时，缓存将变冷，我们实际上必须从主内存重新加载 - 所以我们将获得正确的功能.. 最终(我们自己的进程也可能会换出该缓存行 - 但同样，我们可能会在此之前浪费宝贵的周期)。当通过 DMA Controller 更新主内存时，是否有标准化的硬件支持或操作系统支持通知硬件缓存？或者我们是否必须显式刷新缓存以保证我们不会读取错误值？ (这在列出的架构中甚至可能吗？)
3. 内存映射寄存器，单线程:与 #2 相同，除了 volatile 变量映射到内存映射寄存器(或显式 IO 端口) ).我认为这是一个比 #3 更难的问题，因为至少 DMA Controller 会在传输完成时向 CPU 发出信号，这让操作系统或硬件有机会做一些事情。
4. 多线程:如果我有一个 volatile 变量，是否可以保证在不同物理内核上运行的多个线程之间的缓存一致性？可以肯定的是，编译器仍然从内存中发出加载指令，但是如果该值缓存在一个内核的缓存中，是否可以保证另一个内核的缓存中必须存在相同的值？ (我想这对于同一物理内核上不同逻辑内核上的超线程线程来说根本不是问题，因为它们共享物理高速缓存)。我压倒性的直觉告诉我不会，但我想我还是会在这里列出案例。

如果可能，请区分 x64 和 ARMv6/7/8 架构，以及内核与用户空间解决方案。

Answer 1

对于 2 和 3，没有标准化的方法。

通常在进行 DMA 传输时，人们会以一种平台相关的方式刷新缓存。通常有非常直接的说明来执行此操作(因为现在缓存已集成在 CPU 中)。

另一方面，当访问内存映射寄存器时，行为通常取决于写入顺序。例如，假设您有一个 UART 端口并向其写入字符——您需要确保每次从 C 向它写入时都会实际写入该端口。

虽然它可能会在每次写入之间刷新缓存，但这不是通常的做法。正常方法(至少对于 ARM)是设置 MMU，以便对地址空间的某些区域进行写入时未缓存且顺序正确。

这种方法也可以用于 DMA 传输的内存；例如，可以设置专用区域用作 DMA 缓冲区并设置 MMU，以便对该区域的读取和写入未缓存。

另一方面，该语言保证所有内存(以及您通过声明变量或使用 new 分配内存获得的内存)将以特定方式运行。它是多线程的还是涉及信号之间应该没有区别。请注意，C90 和 C99 标准没有提到线程(C11 有)，但它们应该以这种方式工作。实现必须确保 CPU 和缓存的使用方式与此一致(因此，如果无法完成，操作系统可能无法在不同的内核上安排不同的线程)。因此，您不需要为了在线程之间共享数据而刷新缓存，但您确实需要同步线程，当然还需要使用 volatile 限定数据。信号处理程序也是如此，即使实现恰好将它们安排在不同的内核上也是如此。