Can an Interrupt Handler Be Preempted

Can an interrupt handler be preempted?

Simple answer: An interrupt can only be interrupted by interrupts of higher priority.

Therefore an interrupt can be interrupted by the kernel or a user task if the interrupt's priority is lower than the kernel scheduler interrupt priority or user task interrupt priority.

Note that by "user task" I mean user-defined interrupt.

Can an interrupt handler be preempted by the same interrupt handler?

x86 disables all local interrupts (except NMI of course) before jumping to the interrupt vector. Linux normally masks the specific interrupt and re-enables the rest of the interrupts (which aren't masked), unless a specific flags is passed to the interrupt handler registration.

Note that while this means your interrupt handler will not race with itself on the same CPU, it can and will race with itself running on other CPUs in an SMP / SMT system.

Why processes cannot preempt interrupts?

the first two answers both show some significant misunderstanding about interrupts and how they work

Of particular interest,

for the CPUs that we are usually using

( 86x.., power PC, 68xxx, ARM, and many others)

each interrupt source has a priority.

sadly, there are some CPUs, for instance the 68HC11, where all the interrupts, except the reset interrupt and the NMI interrupt, have the same priority so servicing any of the other interrupt events will block all the other (same priority) interrupt events.

for our discussion purposes, a higher priority interrupt event can/ will interrupt a lower priority interrupt handler.

(a interrupt handler can modify the appropriate hardware register to disable all interrupt events or just certain interrupt events. or even enable lower priority interrupts by clearing their own interrupt pending flag (usually a bit in a register)

In general, the scheduler is invoked by a interrupt handler,

(or by a process willingly giving up the CPU)

That interrupt is normally the result of a hardware timer expiring/reloading and triggering the interrupt event.

A interrupt is really just an event where the event is waiting to be serviced.

The interrupt event, when allowed, for instance by being the highest priority interrupt that is currently pending, will cause the PC register to load the first address of the related interrupt handler.

the act of diverting the PC register to the interrupt handler will (at a minimum) push the prior PC register value and status register onto the stack. (in some CPUs, there is a special set of save areas for those registers, so they are pushed onto the special area rather than on the stack.

The act of returning from an interrupt, for instance via the RTI instruction, will 'automatically' cause the prior PC and status register values to be restored.

Note: returning from an interrupt handler does not clear the interrupt event pending indication, so the interrupt handler, before exiting needs to modify the appropriate register otherwise the flow of execution will immediately reenter the interrupt handler.

The interrupt handler has to, upon entry, push any other registers that it modifies and, when ready to exit, restore them.

Only interrupts of a lower priority are blocked by the interrupt event diverting the PC to the appropriate interrupt handler. Blocked, not disabled.

on some CPUs, for instance most DSPs, there are also software interrupts that can be triggered by an instruction execution.
This is usually used by hardware interrupt handlers to trigger the data processing after some amount of data has been input/saved in a buffer. This separates the I/O from the processing thereby enabling the hardware interrupt event handler to be quick and still have the data processed in a timely manner

The above contradicts much of what the comments and other answers state. However, those comments and answers are from the misleading view of the 'user' side of the OS, while I normally program right on the bare hardware and so am very familiar with what actually happens.

Are there any difference between kernel preemption and interrupt?

When a process is interrupted, the kernel runs some code, which may not be related to what the process does.

When this is done, two things can happen:

1. The same process will get the CPU again.

2. A different process will get the CPU. The current process was preempted.

So preemption will only happen after an interrupt, but an interrupt doesn't always cause preemption.

---

Related Topics