根据 C 规范，中断是信号吗？答案

【问题标题】：Is an interrupt a signal, according to the C spec?根据 C 规范，中断是信号吗？
【发布时间】：2020-07-06 21:42:42
【问题描述】：

C11 5.1.2.3/5：

当抽象机的处理被收据中断时信号的对象的值既不是无锁原子的对象和 volatile sig_atomic_t 类型的对象都未指定，就像浮点环境的状态。任何对象的价值由既不是无锁原子对象也不是无锁原子对象的处理程序修改 volatile sig_atomic_t 类型的在处理程序时变得不确定退出，与浮点环境的状态一样，如果它是由处理程序修改且未恢复到其原始状态。

这个问题专门针对嵌入式系统，在没有类似操作系统的设置的情况下。

在嵌入式系统上，经典信号（POSIX 风格）不存在。假设我们有一个调用多个函数的中断，所有这些函数都在同一个（（半）全局）变量上工作，但这个变量不是在中断外上下文中使用的。类似的东西

static enum State state;

static void setStateTo1(void)
{
    state = stateOne;
}

static void setStateTo2(void)
{
    state = stateTwo;
}

void ISR(void)
{
    if (state == stateOne)
        setStateTo2();
    else
        setStateTo1();
}

两个问题：

中断是信号吗？
上述代码是否是未定义行为的示例，因为state 不是volatile？

【问题讨论】：

如何安装那些“中断处理程序”？如果您为此使用signal，那么这些是标准意义上的信号处理程序，那么是的，您应该只使用volatile sigatomic_t 进行通信。如果这是一组特定于系统的函数，您也必须查看该文档，C 标准无法告诉您任何关于此的内容。
正如问题中所述，这是关于嵌入式系统（我将添加标签以使其更清楚），这实际上是处理器决定我们现在要运行此功能，因为有些事件发生
我们只能假设 C 语言旨在运行在没有 OP 代码指令、汇编语言或中断的特殊设备上。否则，该语言将对计算机具有标准支持。甚至 C++ 也支持内联汇编，但不支持 C。
从纯粹实际的角度来看：由于显示的代码仅从一个线程访问变量（并且 ISR 和它调用的函数是一种线程），我没有看到任何需要将其设为volatile 或原子。话虽如此，您需要确保当 ISR 或任何被调用的函数运行时，它不能再次被调用。这是大多数嵌入式系统的标准，但您可以实现它。并且您需要确保没有其他线程（如main() 及其调用的函数）访问此变量。

标签： c embedded language-lawyer interrupt c11

【解决方案1】：

术语“信号”是指其行为由标准定义的特定事物（C11 7.14“信号处理”）；该定义包括信号有一个数字，并且可以通过跳转到由signal 函数安装的处理程序来中断执行，依此类推。

该标准不涵盖除信号和线程之外的任何其他类型的异步代码执行。

如果您的实现提供了任何其他类型的不符合信号规范的中断，并且中断处理程序改变了抽象机的行为，那么我们可以说该实现不符合标准，或者安装信号处理程序的代码会导致未定义的行为。

要明确定义，您可以让处理程序除了编写易失性原子变量之外什么都不做。

所以，您的第二个问题超出了标准的范围。在标准 C 中，如果程序从未调用过这些函数，优化器可以将所有这些函数删除为未使用。

实际上，提供非标准中断的实现将在自己的权限范围内定义自己的行为，您可以将其视为具有附加功能的 C 语言扩展方言。

【讨论】：

那么根据标准，什么是信号？
确实提到了5.2.3 Signals and interrupts
@P__J__ 如果您参考5.2.3“信号和中断”，它是指执行被信号中断。该标准未涵盖信号以外的任何其他类型的中断。
Functions shall be implemented such that theymay be interrupted at anytime by a signal 任何中断源都是一个信号。
@Cheiron 没有真正的正式定义。 C 语言中的“信号”是利用抽象库 signal.h 的东西。 “符合标准的独立实现”（阅读：嵌入式系统编译器）不需要为 signal.h 提供支持，它是可选的。

【解决方案2】：

该标准的作者认为许多事情在他们的管辖范围之外。如果一个实现使用堆栈的方式在程序执行期间发生任何中断时会发生不可预测的故障，因此要求它生成的代码只能在不会发生中断的情况下运行，这样的限制不会使实现不符合标准，尽管它会使其不适用于许多目的。

设计为适用于特定平台上的低级编程的高质量实现应该期望扩展 C 标准中给出的骨架抽象模型，以包含平台抽象模型中对以下方面有用的任何部分目的，或者记录不这样做的合理理由，但实施质量问题不在标准的管辖范围内。是否应该期望特定实现在超出标准预期的情况下有用，取决于其设计者是否对使其适用于广泛的低级编程任务感兴趣，或者只对适用于标准预期的目的感兴趣.

【讨论】：