Can a running interrupt handler be pre-empted by another interrupt handler? If this is possible, in which scenarios is this safe, and in which scenarios is it not? If this is not possible, why?

  • 3
    $\begingroup$ I can't be remarkably helpful in terms of properly answering the safety part of the question, but from my limited knowledge, interrupts can be interrupted, but only by interrupts of "higher priority". However, the vanilla Linux kernel does not prioritise interrupts, so without some modifications or user-specified priority, the answer is "no". Additionally, so-called "fast interrupt handlers" disable all interrupts on the processor to avoid getting interrupted themselves. $\endgroup$
    – Sebastian Lamerichs
    Aug 19 '14 at 19:12
  • 2
    $\begingroup$ Also, keep in mind that the safety aspect of your question could widely vary depending on what platform (x86, ARM, AVR, et al.) you're using, as well as the configuration of the environment. $\endgroup$
    – Adam Maras
    Aug 19 '14 at 19:22

This depends on both the processor architecture and the kernel architecture.

Generally speaking, interrupt handlers start with interrupts disabled. This is necessary so that the interrupt handler has room for storage — at a minimum, the interrupt handler needs the exclusive use of a few registers, including the program counter, which the processor must save somewhere (in a set of banked registers).

On some processors, it's possible for an interrupt to be interrupted by another higher-priority interrupt. To give one example that I'm familiar with, on ARM processors, there are two interrupt levels: IRQ (normal interrupts) and FIQ (fast interrupts). Each has their own register bank for the program counter and stack pointer, and their own interrupt vector. An IRQ handler starts with IRQ disabled but FIQ enabled; an FIQ handler starts with both IRQ and FIQ disabled. Thus an FIQ can be triggered in the middle of handling an IRQ.

It's up to the operating system to decide when an interrupt handler will reenable interrupts of the same priority, or interrupts of a different type with the same priority. The longer interrupts are blocked, the longer the latency to handle an interrupt that comes soon after another. In particular, a real-time OS typically needs to reenable interrupts very fast. To give a couple of examples:

  • FreeBSD's interrupt handlers can be preempted when they are performing a blocking operation (waiting for a lock).
  • Linux encourages splitting the task of an interrupt handler into two parts: the top half is the actual interrupt handler, and runs with interrupts disabled; the bottom half runs with normal preemption for as long as it needs. Typically the top half exchanges data between hardware peripherals and a preallocated memory buffer, then the bottom half handles all the rest such as communicating with other kernel and userland threads, initiating new hardware I/O, etc.

At the point where an interrupt handler unmasks interrupts, it must be ready to cope: it must not be using any resource that another interrupt handler would thrash. Furthermore, since the interrupt handler hasn't finished its job, there must be some mechanism for the program counter to be saved somewhere; the mechanics of this depends a lot on both the processor and the kernel architecture.

  • $\begingroup$ In Linux, is this part of the softIRQ system or is this just an integral part of the interrupt handlers? $\endgroup$
    – David Kohen
    Aug 25 '14 at 15:52
  • 1
    $\begingroup$ @DavidKohen Linux's softIRQs are a type of bottom half, as far as I understand — so I think it's the other way round, the softIRQ system is part of “this”. $\endgroup$ Aug 25 '14 at 18:23
  • $\begingroup$ @Gilles: Can I use your answer as a part of my lecture notes on OS? $\endgroup$
    – unxnut
    Aug 27 '14 at 18:47
  • $\begingroup$ @unxnut Sure. You're welcome to use it under CC BY-SA with attribution to Gilles on Stack Exchange (preferably hyperlinked to this answer if it ends up being public and the medium of your lecture notes allow hyperlinks, so that readers can see any update, but don't worry about it if a hyperlink isn't practical). If CC BY-SA isn't ok for you, we can discuss it in chat. $\endgroup$ Aug 27 '14 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.