What Are Nested Interrupts and How Are They Handled?
Learn what nested interrupts are — priority preemption, stacked contexts, and priority inversion — with OS interview questions answered.
Expected Interview Answer
A nested interrupt occurs when a higher-priority interrupt is allowed to preempt a currently executing lower-priority interrupt handler, so the CPU suspends the first handler mid-run, services the new one, and only then resumes the original — requiring careful priority-based masking so handlers can be interrupted safely without corrupting shared state.
By default, most architectures automatically mask further interrupts the moment a handler begins running, ensuring one handler completes before another starts; nesting happens only when a handler explicitly re-enables interrupts (or the hardware supports priority levels) and a strictly higher-priority interrupt arrives during that window. When that happens, the CPU saves the currently executing handler’s own context on top of the original interrupted task’s context — effectively stacking multiple saved contexts — masks interrupts at or below the new priority level, and jumps to the higher-priority handler. Once that finishes, it returns to the interrupted lower-priority handler, which resumes and eventually returns to the original task, unwinding the stack of saved contexts in reverse order like nested function calls. This is essential for real-time systems where a critical event, such as a hardware fault or a time-sensitive sensor reading, must never wait behind a slower device handler, but it introduces real risk: shared data structures accessed by both handlers need protection (disabling interrupts briefly, or using lock-free techniques), stack depth must be bounded to avoid overflow from deep nesting, and priority levels must be assigned carefully to avoid priority inversion, where a low-priority handler indirectly blocks a high-priority one.
- Explains priority-based interrupt masking, not just accept-or-reject
- Clarifies the stacked-context model, analogous to nested function calls
- Surfaces real risks: shared-state races, stack depth, priority inversion
- Grounds why real-time systems rely on nested interrupt support
AI Mentor Explanation
Nested interrupts are like a physio being called onto the field for a minor knock, and mid-treatment a second, more serious collapse happens elsewhere: the physio pauses the first treatment exactly where it stood, rushes to the more urgent case, and only returns to finish the first once the serious case is stabilized. This only works because there is a clear priority ranking — serious collapses always outrank minor knocks — and each paused case is tracked precisely so nothing is lost. If priorities were not respected, a minor case could keep a life-threatening one waiting, which is exactly the danger of priority inversion.
Step-by-Step Explanation
Step 1
First interrupt handled
A lower-priority interrupt fires and its handler begins running, with interrupts masked at its own priority level by default.
Step 2
Handler re-enables interrupts
The handler explicitly unmasks higher-priority interrupts (or the hardware auto-supports priority levels), opening a nesting window.
Step 3
Higher-priority interrupt preempts
A strictly higher-priority interrupt arrives; the CPU saves the running handler's context on top of the stack and jumps to the new handler.
Step 4
Unwind in reverse
The higher-priority handler finishes and returns to the first handler, which finishes and returns to the originally interrupted task — contexts unwind like nested calls.
What Interviewer Expects
- Understanding that nesting requires explicit priority-based preemption, not automatic
- The stacked-context model: contexts save and unwind like nested function calls
- Awareness of shared-state race risks between nested handlers
- Knowledge of priority inversion as a real risk of poorly designed nesting
Common Mistakes
- Assuming all interrupts nest freely by default without any masking
- Not knowing that interrupts are typically masked automatically inside a handler
- Ignoring the risk of stack overflow from unbounded interrupt nesting depth
- Not recognizing priority inversion as a consequence of poor nested-interrupt design
Best Answer (HR Friendly)
“Nested interrupts happen when a more urgent interrupt is allowed to interrupt an interrupt handler that is already running, so the system pauses that handler exactly where it was, deals with the more urgent event first, and then goes back and finishes the original one. This matters for time-critical systems where a truly urgent event should never be stuck waiting behind a less important one, but it has to be done carefully so shared data does not get corrupted and the priority ordering is genuinely respected.”
Code Example
#define PRIO_TIMER 1
#define PRIO_CRITICAL 5 /* higher number = higher priority */
volatile int current_priority = 0;
void timer_handler(void) {
int saved_priority = current_priority;
current_priority = PRIO_TIMER;
enable_interrupts_above(PRIO_TIMER); /* allow nesting for higher prio */
/* ... routine timer bookkeeping, interruptible ... */
disable_interrupts();
current_priority = saved_priority; /* unwind, like a nested call */
}
void critical_fault_handler(void) {
int saved_priority = current_priority;
current_priority = PRIO_CRITICAL;
/* Highest priority: not preempted by anything else in this system */
handle_critical_fault();
current_priority = saved_priority; /* return to whatever nested us */
}Follow-up Questions
- What is priority inversion, and how does it relate to nested interrupts?
- Why must interrupt handlers avoid unbounded recursion or deep nesting?
- How do critical sections inside a handler protect data shared with a nesting interrupt?
- How does a real-time OS bound worst-case interrupt latency in the presence of nesting?
MCQ Practice
1. What is required for one interrupt handler to be preempted by another?
Nesting only occurs when a higher-priority interrupt is allowed through the current mask level while a lower-priority handler runs.
2. How are contexts managed across nested interrupts?
Each preempted handler's context is saved on top of the previous one and restored in LIFO order as handlers complete.
3. What risk is specifically associated with poorly designed nested interrupts?
If priority levels or shared locks are mismanaged, a lower-priority handler can end up blocking a higher-priority one, defeating the purpose of nesting.
Flash Cards
What is a nested interrupt? — A higher-priority interrupt preempting a currently running lower-priority interrupt handler.
How are nested interrupt contexts managed? — Stacked and unwound in reverse order, like nested function calls.
What enables nesting to happen at all? — A handler explicitly re-enabling higher-priority interrupts, or hardware priority-level support.
What is the key risk of nested interrupts? — Priority inversion and shared-state races between the nested handlers.