volatile sig_atomic_t 的内存安全答案

【问题标题】：memory safety of volatile sig_atomic_tvolatile sig_atomic_t 的内存安全
【发布时间】：2019-03-09 12:40:01
【问题描述】：

volatile sig_atomic_t 是在信号处理程序和主应用程序之间共享数据的有保证的安全方式。当在具有更宽松内存模型的现代 CPU 上运行时，Posix 会做出什么内存排序保证。具体来说，在使用volatile sig_atomic_t 读取或写入数据时是否应该使用内存屏障/内存栅栏？

编辑：只是为了澄清。我的问题是，在使用 sig_atomic_t 时，我们如何保证在宽松的内存排序方面不会发生坏事，尤其是在现代高度缓存、多核等架构中。

【问题讨论】：

如果需要显式指定内存排序，请使用 C11 或 C++11 原子类型。
我相信 sig_atomic_t 早于 C++11，而现在你改用 C++11 原子。
另外，如果我必须使用原子，那么 volatile sig_atomic_t 永远不会安全。
无论如何，C 和 C++ 都有一个atomic_signal_fence() 函数，用于协调线程和在该线程上调用的信号处理程序之间的非原子类型（和需要锁定的原子类型）顺序。但是，如果您坚持使用不应该需要的 volatile sig_atomic_t 变量。
关于 volatile sig_atomic_t 见 Linux 编程接口第 21.1.3 节

标签： c++ c linux signals

【解决方案1】：

POSIX 目前不做任何内存排序保证，因为它还没有与 C++ (C11) 内存模型集成。

C11 确保 volatile sig_atomic_t 类型的对象在信号处理程序中保留它们的值，即使没有栅栏。其他对象在访问时具有不确定的值。 atomic_signal_fence 的名称有误，因为按照标准中的规定，它不能用于访问其他类型的对象（volatile sig_atomic_t 除外），以便它们在信号处理程序中保留其值。

对于异步信号，可以通过在专用线程中处理它们并为所有其他线程阻塞它们来避免这些问题。对于大多数同步信号（例如由整数除以零触发的SIGFPE，或用于访问未映射内存的SIGBUS 或SIGSEGV），我认为没有任何标准规定会发生什么。这真的很奇怪，因为异步信号应该更难处理，但目前情况正好相反。

【讨论】：