Take the 2-minute tour ×

Why can't a context switch happen when an interrupt handler is executing ? More specifically, in the linux kernel, interrupt handlers run in the context of the process that was interrupted. Why is it not possible to do a context switch in the interrupt handler to schedule another process ?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

On a multiprocessor, a context switch can certainly happen while an interrupt handler is executing. In fact, it would be difficult to prevent.

On a single-CPU machine, by definition it can only be running one thread of control at a time. It only has one register set, one ALU, etc. So if the interrupt handler is running there simply are no resources with which to execute a context switch.

Now, if you mean, can the interrupt handler actually call the context switch code and make one happen, well, I suppose on some systems that could be made to work. But for most, this wouldn't have much value and would be difficult to arrange. The CPU is running at elevated priority, and this priority cannot be lowered or synchronization between interrupt levels is lost. Critical sections in the OS are already synchronizing against interrupt execution and this would introduce complexities. Furthermore, a context switch happens by changing stacks, much like in a threaded user mode program, so it's hard to imagine how this might happen when the interrupt stack is needed for a return from the interrupt.

share|improve this answer
Thanks for the reply. I meant the interrupt handler calling schedule(). Can you please elaborate on " it's hard to imagine how this might happen when the interrupt stack is needed for a return from the interrupt" ? –  Bandicoot Jan 19 '11 at 7:06
In a context switch, a given kernel thread calls to the switch code which changes switches stacks. Now, the process it is switching to ALSO got to the context switch code by calling the similar code, so when the CPU returns on the new stack after the switch, it will return from the sleep function that it called. None of that can happen from interrupt code, because it needs to return and lower the CPU priority. We wouldn't want to save the stack of a half-executed interrupt routine and also accidentally leave the CPU at interrupt priority. (That would lock out further interrupts.) –  DigitalRoss Jan 19 '11 at 17:14

A couple reasons, I guess, depending on the meaning of your question:

  1. Interrupts are generally for interacting with hardware. Hardware is typically time-sensitive so the OS can't just stop dealing with it in the middle of something and comes back when it feels like it.

  2. An interrupt happens in a special interrupt context, not a regular process context. Since it's not in a process, it's not subject to context switching as a normal process would be.

There's probably a better, deeper explanation to be made, but that's the extent of my own understanding of the matter.

share|improve this answer

Your Answer


