Linux：为什么 sig_atomic_t 类型定义为 int？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9606725/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Linux: Why is sig_atomic_t typedef'ed to int?
提问by smcdow
On my Linux box, sig_atomic_tis a plain old int. Do intsposses a special atomic quality?
在我的 Linux 机器上，sig_atomic_t是一个普通的旧int. 是否ints具有特殊的原子质量？
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
...
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
$ echo '#include <signal.h>' | gcc -E - | grep atomic
typedef int __sig_atomic_t;
typedef __sig_atomic_t sig_atomic_t;
采纳答案by zwol
C99 sig_atomic_tconforms only to a very weak definition of "atomicity", because C99 has no concept of concurrency, only interruptibility. (C2011 adds a concurrency model, and with it the _Atomictypes that make stronger guarantees; however, AFAIK sig_atomic_tis unchanged, since its raison d'êtreis still communication with signal handlers, not across threads.)
C99sig_atomic_t只符合“原子性”的一个非常弱的定义，因为C99 没有并发的概念，只有可中断性。（C2011 添加了一个并发模型，以及提供_Atomic更强保证的类型；然而，AFAIKsig_atomic_t没有改变，因为它的存在理由仍然是与信号处理程序通信，而不是跨线程。）
This is everything C99 says about sig_atomic_t:
这就是 C99 所说的一切sig_atomic_t：
(§7.14
<signal.h>, paragraph 2) The type defined issig_atomic_t, which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. (§7.14<signal.h>, paragraph 2)(§7.14p5) If [a] signal occurs other than as the result of calling the
abortorraisefunction, the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared asvolatile sig_atomic_t.(§7.18.3 Limits of other integer types, paragraph 3) If
sig_atomic_t(see 7.14) is defined as a signed integer type, the value ofSIG_ATOMIC_MINshall be no greater than ?127 and the value ofSIG_ATOMIC_MAXshall be no less than 127; otherwise, sig_atomic_t is defined as an unsigned integer type, and the value ofSIG_ATOMIC_MINshall be 0 and the value ofSIG_ATOMIC_MAXshall be no less than 255.
（
<signal.h>第7.14 节，第 2 段）定义的类型是sig_atomic_t，它是对象的（可能是 volatile 限定的）整数类型，即使存在异步中断，也可以作为原子实体访问。（<signal.h>第7.14 节，第 2 段）（第 7.14p5 节）如果 [a] 信号发生而不是调用
abortorraise函数的结果，如果信号处理程序引用任何具有静态存储持续时间的对象，而不是通过将值分配给声明为 的对象，则行为未定义volatile sig_atomic_t。（第 7.18.3 节其他整数类型的限制，第 3 段）如果
sig_atomic_t（见 7.14）被定义为有符号整数类型，则 的值SIG_ATOMIC_MIN应不大于 ?127 且值SIG_ATOMIC_MAX应不小于 127；否则，sig_atomic_t定义为无符号整数类型，其值为SIG_ATOMIC_MIN0，SIG_ATOMIC_MAX且不小于255。
The term "atomic entity" is not defined anywhere in the standard. Translating from standards-ese, the intentis that the CPU can completely update a variable of type sig_atomic_tin memory ("static storage duration") with one machine instruction. Thus, in the concurrency-free, precisely interruptible C99 abstract machine, it is impossible for a signal handler to observe a variable of type sig_atomic_thalfway through an update. The §7.18.3p3 language licenses this type to be as small as charif necessary. Note please the complete absenceof any language relating to cross-processor consistency.
标准中的任何地方都没有定义术语“原子实体”。从标准 ese 翻译过来，目的是 CPU 可以sig_atomic_t用一条机器指令完全更新内存中的类型变量（“静态存储持续时间”）。因此，在无并发、精确可中断的 C99 抽象机中，信号处理程序不可能在sig_atomic_tupdate 中途观察到类型变量。§7.18.3p3 语言许可这种类型在必要时尽可能小char。请注意，完全没有任何与跨处理器一致性相关的语言。
There are real CPUs which require more than one instruction to write a value larger than charto memory. There are also real CPUs which require more than one instruction to write values smaller than a machine word(often, but not necessarily, the same as int) to memory. The language in the GNU C Library manual is now inaccurate. It represents a desire on the part of the original authors to eliminate what they saw as unnecessary license for C implementations to do weird shit that made life harder for application programmers. Unfortunately, that very license is what makes it possible to have C at all on some real machines. There is at least one embedded Linux port (to the AVR) for which neither intnor pointers can be written to memory in one instruction. (People are working on making the manual more accurate, see e.g. http://sourceware.org/ml/libc-alpha/2012-02/msg00651.html-- sig_atomic_tseems to have been missed in that one, though.)
有一些真实的 CPU 需要不止一条指令来写入大于char内存的值。也有真正的 CPU 需要多条指令才能将小于机器字（通常但不一定与 相同int）的值写入内存。GNU C 库手册中的语言现在不准确。它代表了原作者的一种愿望，即消除他们认为不必要的 C 实现许可，以做一些奇怪的事情，这让应用程序程序员的生活变得更加艰难。不幸的是，正是这种许可使得在某些真实机器上完全可以使用 C。至少有一个嵌入式 Linux 端口（到 AVR）int也不能在一条指令中将指针写入内存。（人们正在努力使手册更准确，例如参见http://sourceware.org/ml/libc-alpha/2012-02/msg00651.html——不过，sig_atomic_t似乎已经错过了那个。）
回答by perreal
Certain types may require multiple instruction to read/write. inttype is always read/written atomically.
某些类型可能需要多条指令来读/写。int类型总是以原子方式读/写。
Data Type: sig_atomic_t
This is an integer data type. Objects of this type are always accessed atomically.
In practice, you can assume that int and other integer types no longer than int are atomic. You can also assume that pointer types are atomic; that is very convenient. Both of these are true on all of the machines that the GNU C library supports, and on all POSIX systems we know of.
数据类型：sig_atomic_t
这是整数数据类型。这种类型的对象总是以原子方式访问。
在实践中，您可以假设 int 和其他不超过 int 的整数类型是原子的。你也可以假设指针类型是原子的；那很方便。在 GNU C 库支持的所有机器上，以及我们所知的所有 POSIX 系统上，这两者都是正确的。
