Question

I have some confusion when looking at how interrupt handler(ISR) is run. In Wiki http://en.wikipedia.org/wiki/Context_switch, it describes interrupt handling with 2 steps:

1) context switching

When an interrupt occurs, the hardware automatically switches a part of the 
context (at least enough to allow the handler to return to the interrupted code).
The handler may save additional context, depending on details of the particular
hardware and software designs.

2) running the handler

The kernel does not spawn or schedule a special process to handle interrupts, 
but instead the handler executes in the (often partial) context established at 
the beginning of interrupt handling. Once interrupt servicing is complete, the 
context in effect before the interrupt occurred is restored so that the 
interrupted process can resume execution in its proper state.

Let’s say the interrupt handler is the upper half, is for a kernel space device driver (i assume user space device driver interrupt follow same logic).

when interrupt occurs:

1) current kernel process is suspended. But what is the context situation here? Based on Wiki’s description, kernel does not spawn a new process to run ISR, and the context established at the beginning of interrupt handling, sounds so much like another function call within the interrupted process. so is interrupt handler using the interrupted process‘s stack(context) to run? Or kernel would allocate some other memory space/resource to run it?

2) since here ISR is not a ‘process’ type that can be put to sleep by scheduler. It has to be finished no matter what? Not even limited by any time-slice bound? What if ISR hang, how does the system deal with it?

Sorry if the question is fundamental. I have not delved into the subject long enough.

Thanks,

Answer 1

so is interrupt handler using the interrupted process’s stack(context) to run? Or kernel would allocate some other memory space/resource to run it?

It depends on the CPU and on the kernel. Some CPUs execute ISRs using the current stack. Others automatically switch to a special ISR stack or to a kernel stack. The kernel may switch the stack as well, if needed.

since here ISR is not a ‘process’ type that can be put to sleep by scheduler. It has to be finished no matter what?

Yep, or you’re risking to hang your computer. You see, interrupts interrupt processes and threads. In fact, most CPUs have no concept of a thread or a process and to them it doesn’t matter what gets interrupted/preempted (it can even be another ISR!), it’s just not going to execute again until the ISR finishes.

Not even limited by any time-slice bound? What if ISR hang, how does the system deal with it?

It hangs, especially if it’s a single-CPU system. It may report an error and then hang/reboot. In fact, in Windows (since Vista?) hung or too slowly executing deferred procedures (DPCs), which aren’t ISRs but are somewhat like them (they execute between ISRs and threads in terms of priority/preemption) can cause a “bugcheck”. The OS monitors execution of DPCs and it can do that concurrently on multiple CPUs.

Anyway, it’s not a normal situation and typically there’s no way out of it other than a system reset. Look up watchdog timers. They help to discover such bad hangs and perform a reset. Many electronic devices have them.