在哪些情况下可能会中断/抢占不同的中断处理程序？答案

【问题标题】：In which cases different interrupt handlers may be interrupted / preempted?在哪些情况下可能会中断/抢占不同的中断处理程序？
【发布时间】：2020-04-23 11:07:44
【问题描述】：

中断分为三种：

外部
内部（软件中断）
系统调用（基于内部）

我有一个问题“调度程序可以中断或抢占中断（这也是计时器中断）吗？”

经过一番研究，我完全糊涂了：

有人说中断有优先级，只有优先级较高的中断才能中断另一个。 它只与外部中断有关吗？ / 它在实际操作系统中是如何安排的，比如 x86-64 Linux？它被使用了吗？ / 好的，如果某些中断被中断，它会恢复吗？有人说中断没有“上下文”，但据我所知，抢占了一些进程/ 线程发生在来自计时器的中断时，因此可以将上下文切换回已发生的中断以抢占进程。 如果我错了，请纠正我。
有人说有一些中断处理程序“INTERRUPTIBLE”的标志，假设如果某个系统调用处理程序正在执行此标志设置，它可能会被信号中断。 是否仅与软件中断有关？外部中断没有那个标志吗？ / 如果没有设置这个标志但是定时器（例如）中断发生抢占线程怎么办？它被忽略了吗？
有人说它只取决于中断处理程序在做什么。例如，如果有 read() 系统调用正在等待输入，它会设置特定的标志，以便调度程序（定时器中断）可以中断并抢占它。但是如果处理程序正在做一些重要的事情，它可以禁止中断或抢占它，所以它会自己拥有一个 cpu 直到它完成。 x86 中似乎有很多机制，我不完全了解使用的是哪一种以及它在现实生活中是如何工作的。

【问题讨论】：

虽然确实存在不同类型的“中断”，但系统调用绝对不是其中之一。系统调用只是进入内核空间以运行内核代码并从系统中提取所需信息的任务，它不会真正“中断”任何东西。
任何时候内核知道它需要阻塞，它都会调用schedule()。例如读取系统调用发现必要的页面在磁盘上，而不是在页面缓存中，将调用函数来开始 I/O，但是然后它不是忙于等待 I/O，而是设置了一些东西，所以这个任务将是当页面准备好时由调度程序唤醒。这不是抢占，这是另一个任务的自愿调度。
@MarcoBonelli：使用 32 位系统调用 ABI 的传统方式是 int 0x80 指令。这通常称为软件中断，但是是的，它是同步的，而不是异步的。（有趣的事实：即使中断被禁用，它仍然可以正常工作。）所以我理解为什么 OP 使用了那个令人困惑的术语。（系统调用等更像是同步异常，比如页面错误。What happens to software interrupts in the pipeline? 涵盖了 CPU 架构细节，但不包括软件/操作系统细节）
@PeterCordes，好的，谢谢，它澄清了一些事情。但是我仍然不明白在这两种情况下发生了什么，例如：1.如果处理程序已经消耗了它的时间量，系统调用处理程序是否会被计时器（调度程序）中断和抢占？ 2. 相同的情况，但使用外部中断而不是系统调用？
是的，大多数内核代码都可以被抢占。真正的 IRQ 处理程序（Linux 称之为“上半部分”处理程序）可能不可中断，或者至少不可抢占（如果嵌套的 IRQ 处理程序运行，它需要直接返回，而不是安排其他事情）。

标签： linux linux-kernel x86 interrupt preemption

【解决方案1】：

（回答 x86 上的 Linux，因为这些是您的标签）。

只有两种类型的事件会中断您的代码。中断和异常。系统调用被视为异常。

我有一个问题“调度程序可以中断或抢占中断（这也是计时器中断）吗？”

调度程序不会中断任何事情。它只是代码，它不能自行运行。只有中断或异常才能中断您的代码。您可以让定时器中断发生，然后调用 schedule()。

如果您处于中断状态，则可能会禁用中断。所以没有定时器中断，因此没有 schedule()。如果您处于启用中断的中断中（允许嵌套中断），则计时器中断可能会尝试调用调度程序，但它不会运行，因为它会检测到抢占被禁用。当您通过 preempt_count 字段处于中断状态时，总是禁用抢占。这里的目标是防止在中断上下文中抢占。

您还有很多其他问题，但大多数问题都可以通过阅读有关该主题的现有文献来回答。

【讨论】：