What happens to preempted interrupt handler?

Question

I could not find a proper answer for the following questions even in some well written kernel books:

1. They are saying that an ISR can't sleep because its not possible to reschedule an ISR as it is not connected with any process , so what happens when a higher priority interrupt preempt the executing one? the interrupted ISR will not rescheduled(execute) again ? if yes how & who will do that work?

2. many time we will disable interrupt (eg: 1.In critical region 2. When a fast interrupt is executing it will disable all the interrupt in the current processor) , so what will happen for the interrupts that are occurring when interrupts are disabled ? they are simply discarded? or will be stored somewhere for later execution? if yes where & how?

3. when an ISR is executing it will disable interrupt in the current IRQ line to avoid reentrant(preventing another ISR on the same line from being executed), but why? whats wrong if an ISR is reentrant?

*ISR=Interrupt Service Routine

*They=Book's author

Answer 1

1. Yes, in OS, only tasks is scedhuled in Round-Robin fashion. The goal of scheduling is to share CPU resource, fairly share CPU's execution power to each running tasks. The interrupt itself, is to handle a specific event and each interrupt has its own priority. Higher priority interrupt may preempt the running low priority ISR.

   How it works is based on a interrupt mask register on interrupt controller, when ISR starts it set the mask register to disable interrupts with lower priorities, and before ISR return, it restore the mask register to allow lower priority interrupts.

2. The interrupt handle requests is proposed by hardware device, it pull down an interrupt pin to the interrupt controller when data arrival. If the intterupt is disabled ( mask is set ), the request from hardware is pending and the interrupt pin is kept low. The interrupt will happen again once the interrupt is enabled (mask is clear).

3. The CPU will continously trigger interrupts and eventaully get stackoverflow!

Answer 2

An interrupt traps the execution from user space to kernel by first saving the current CPU states and forcing the program counter (PC) to jump to the location of the interrupt vector table. The table then provides a pointer to the (sequence of) kernel function(s) that saves the current process states and maps the interrupt ID to the start of the ISR. When a higher priority interrupt occurs during an ISR, the same sequence of events happens, except both the running ISR and and the incoming interrupt are handled by the same (kernel) process, therefore no process is put to sleep.

New interrupts are of course ignored if it is disabled. However, an interrupt can be pending if it's enabled while the processor is serving a higher-priority interrupt.

ISR is a function call within the kernel space and requires allocating its own stack. Reentrant interrupts can cause stack overflow if there are too many preemptions. Most kernels (including Linux and Windows) have a fixed stack size.

Answer 3

I'll try to answer 1 of your questions. answer to 1) ISR can't sleep because they run in the context of the currently running process. If they sleep, the currently running process will be moved to sleep state. That is undesirable.

Answer 4

As far as I know a ISR can be pre-empted by another interrupt, and continue running after that . I see no reason why a process could be put on the stack and a ISR not.

Processes are an operating system level thing, while ISRs are a CPU level thing. If you call sleep() in a process, you tell the operating system that you have no work right know and that it may run another process. This is not applicable to ISRs.

Also, what is meant by disabling interrupts?