Why do we have multiple Interrupt Handlers in a system rather than just one?

Question

In the Kernel of an operating system, we have an Interrupt table that contains many interrupt handlers that handle interrupts from I/O devices and processes. But why can't we just have one interrupt handler? Are interrupt handlers any different from each other?

Answer 1

Another issue is that, with one interrupt-handler, it gets very messy to prioritize interrupts.

Usually, interrupts are disabled in hardware once an interrupt is acknowledged by the CPU that handles it, so preventing multiple, reentrant invocations of the same interrupt and any issues with data/buffer overwrites that would likely ensue. It's also common for an interrupt-handler to propmptly re-enable interrupts of a higher priority, so improving response to those interrupts, (they can then interrupt the lower-priority interrupts).

Using only one interrupt-handler would make prioritizing interrupts exrtemely messy, if possible at all:(

Getting interrupt handlers and drivers to cooperate harmoniously is difficult enough as it is!

Are interrupt handlers any different from each other?

Well, yes. They may all be forced to conform to a set of rules/constraints by the OS design, but yes, they are generally different. A handler that manages an interrupt from a disk DMA controller will surely have different code than a keyboard input handler. They manage different hardware, to start with:)

Answer 2

In principle there is no reason why you could not have a single interrupt handler that gets called for all interrupts. Such a handler would have to check every single interrupt source. Since most of the time only a small fraction of the possible interrupt sources are active, many cycles would get wasted checking to see which interrupt was triggered. Since ISR routines are generally very frequently called code you would take a large (probably unacceptable) performance hit.

The way a specific interrupt controller handles interrupts can vary quite a bit. To get a very solid understanding you'd have to read the manuals for a variety of different architectures interrupt controller implementations.

However, some interrupt controllers do end up sharing a common ISR routine. The common ISR will read registers in the interrupt controller to determine what vector (basically the source of the interrupt) was triggered. The common ISR then calls another function (that is often referred to as an interrupt service routine as well) that handles that specific interrupt source based off the vector value. Then depending on the implementation of the interrupt controller when the vector specific routine returns control to the common ISR, the common ISR will deassert the interrupt on the interrupt controller returning execution back to the interrupted place in code. Thus, by reading the vector from the a register in the interrupt controller cycles are saved because the common ISR knows what caused the interrupt, rather than examining every possible interrupt source.

Answer 3

If you have one interrupt handler, the decision for how the interrupt should be processed is made in code instead of in hardware.

And there are a LOT of things that can trigger an interrupt - so the code would almost certainly reduce overall performance.