Context Switch in Interrupt Handlers

Context switch in Interrupt handlers

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.

Context switch interrupt handler

The OS can do a context switch from the timer IRQ handler if it wants to. This is generally what happens to CPU-hog processes when they've used up their timeslice. (The kernel returns to a different process / thread, instead of back to the context that was running when the IRQ fired.)

Maybe https://en.wikipedia.org/wiki/Preemption_(computing)#Time_slice can help?

Interrupts and context switches

When the mentioned registers were recovered by the interrupt handler, why is the iret called? On switching the thread, the next thread will start immediately

You say, "on switching the thread," but the iret instruction is what makes the thread switch happen.

or is he starting after finishing the interrupt handler with the iret call?

Don't think of iret as "return from interrupt." Think of it as,"restore execution context" instead. It pops words from the stack into important context registers, always including the program counter, and maybe including registers that define virtual address space and privilege level. The next instruction that the CPU executes after the iret will be an instruction from the newly restored context.

The saved context that iret pops off the stack happens to be the same format as what a hardware interrupt pushes, but that doesn't mean that you can only pop the context that was pushed by the most recent hardware interrupt. You can pop a context that was pushed some time earlier, and then saved in some "thread" data structure. You can even pop an entirely new context that was manufactured from nothing in order to start a new thread.

How does interrupt polling perform context switching?

Well, you are generally correct that the kernel can't do multitasking until it gains control of the CPU. That happens via an interrupt or when user code makes a system call.

The timer interrupt, in particular, is used for preemptive time slicing. I think it would be pretty hard to find a whole CPU that didn't support a timer interrupt, that you didn't have to program with punch cards or switches. Interrupts are much older than multiple cores or virtual memory or DMA or anything fancy at all.

Some SoCs have real time sub-components that have this sort of restriction (like Beaglebone), and it might come up if you were coding a small CPU in an FPGA or something.

Without interrupts, you have to wait for system calls, which basically becomes cooperative multitasking.

---

Related Topics