In hardware and software interrupt flow how queue up is handled? more precisely I have following doubts

Lets take a scenario I have a machine with 2 CPUs. CPU1 is processing process P1 and CPU2 is processing process P2. Process P3 is waiting for execution. Now CPU1 got the hardware interrupt (I1). so, CPU1 context switched to interrupt service routine (ISR) for I1.

Note: we can ignore the bottom half of interrupt and consider all interrupt has only top half.

  • Once interrupt handling for I1 completed. Is it guarantee that P1 will be scheduled again or Is there a chance for P3 to be scheduled?
  • Will process P1 (It is removed from CPU1 due to hardware interrupt) occupy CPU2 if it is free?
  • What will happen to second interrupt I2 if the interrupt handler of I1 is not masked any interrupt? If it will queue up who will remember that queue?
  • What will happen to second interrupt I2 if the interrupt handler of I1 is masked all interrupt?

2 Answers 2


Usually, interrupt handlers are designed to be as short as possible, and the actual handling code is called in a process-like context. The handler just determines the source, adds a queue entry in software and disables the interrupt source afterwards. When the CPU returns from interrupt processing, the queue of interrupt handlers is processed first, then whatever process is "current" is resumed.

Handlers called during queue evaluation can change which process is "current", the most obvious example is the timer interrupt indicating that a time slice is up, but incoming events can also make higher-priority processes runnable, which would schedule them.

Multi-processor systems have explicit interrupt routing, typically with a dedicated timer IRQ that is only routed to its associated CPU, and hardware interrupts having either a "preferred" CPU (for improved cache locality) or a load balancing approach applied to them where the interrupt controller makes sure to distribute them.

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 handler (and the length of this queue is limited because only one instance of each source can be queued).

So, the "bottom-half" handler that interfaces with one particular piece of hardware can be interrupted by another incoming interrupt, but all that does is add the second interrupt to the queue. The bottom-half handler for the first interrupt is then resumed, when that returns, the bottom-half handler for the second interrupt is invoked, and as soon as the queue of bottom-half handlers becomes empty, the current user-space process is executed.

  • tnx Simon for your response, still I was not able to find the answer to most of my doubt. Commented Feb 24, 2020 at 12:37

There is no guarantee on the process run next. Each time an interrupt is handled, the kernel determines what to schedule next (an higher priority process that became runnable, the current process' priority went down and another one's turn is up, ...). The cache's contents are shot anyway, so there is not much point in always resuming the running process. And what happens is strictly an internal kernel matter, the policy used can change without warning.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .