Menu
My platform is x86 and x86-64, on Windows.
The point of the interrupt priority system is to have the highest priority interrupt beat out the others. To enforce this, I'm guessing that Windows will disable all interrupts of lower level completely, until the ISR for the higher-level interrupt is complete.
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again? If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed? What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
958
Whenever disabling interrupts, the CPU will be unable to switch processes and processes can use shared variables without another process accessing it. The most obvious way to achieve mutual exclusion is to allow a process to disable interrupts before it enters critical sections.
From the hardware point of view, interrupts are always flagged, not queued, so an interrupt cannot be sent again until it is handled (so there is no hardware limitation that loses interrupts if the rate is too high), but the OS generally keeps a queue in software so it spends as little time as possible in a "real" IRQ ...
Most hardware doesn't "lose" an interrupt. During an interrupt, the CPU's "interrupt flag" is cleared, but the interrupt controller [a separate beast] is still available/enabled to note new interrupts.
The processor samples the interrupt input signal during each instruction cycle. The processor will recognize the interrupt request if the signal is asserted when sampling occurs. Level-triggered inputs allow multiple devices to share a common interrupt signal via wired-OR connections.
Some background
Interrupts from the peripherals are not directly handled by the CPU, instead by a hardware called "Programmable Interrupt Controller". Earlier systems used a PIC - (Intel 8259) but due to its lack of support for SMP systems, nowadays Adavnced PIC - APIC (Intel 82093) is used. APIC has two components, IO APIC (part of motherboard) forwards these interrupt requests to the local APIC (part of the CPU).
But these hardwares just pass the messages to the CPU, the actual handling is done by the device driver of the particular device.
Now to your questions
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again?
This article talks about two classes of interrupts handlers depending upon how fast they are executed:
1. Fast: Run with further interrupts disabled,
2. Slow: Run with interrupts enabled.
But now the distinction between the two has become obsolete since tasklets/work queues (top & bottom halfs - rings a bell?) have made the execution time of the handlers very less, hence nowadays interrupts handlers are run with interrupts enabled. For slower devices like I2C, we have moved to a new technique called Threaded Interrupt Handler, which is even better than the top/bottom half approach. In case for some device if the above techniques don't work, than the handler is executed with interrupts disabled and yes in that case, you keep losing the interrupts, but I can't find any instance where such a thing happens.
If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed?
No, they are not queued up, it is a bad interrupt handler design if the interrupts need to be disabled and that too for a longer time.
What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
If the interrupts are disabled then there nothing that you can do, but if they are enabled and you keep getting more interrupts then it leads to nesting of interrupts, to the extent that the system might crash. A core dump then can be used to detect the cause.
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
