Why interrupt handlers (ISRs) cannot sleep?

Question

I am very confuse to get why interrupt handler can't sleep? i got 2 views for the same issue:-

1. Interrupt Handler is not schedulable? Because it has no task_struct.

2. if the handler sleeps, then the system may hang because the system clock interrupt is masked and incapable of scheduling the sleeping process.

Are interrupt handlers schedule-able,
but while the lower priority system clock interrupt
is masked by these higher priority interrupts,
they cannot be scheduled?

Please give me a good example for the same.

Answer 1

Attempting to answer this from a more concrete point of view

Let’s address how sleeping works first:

Sleeping is implemented by moving the current task_struct from the run queue to a sleep queue and invoking the scheduler to run the next task. For example, a struct mutex contains a sleep queue. A sleeping task will not run until someone else wakes/moves the task back into the run queue, such as with mutex_unlock().

Here are the issues:

1. When running in hard or soft IRQ, the current task is hijacked. It does not belong to the IRQ and might not have any relationship to it. Going into sleep now means this victim task will not run until the IRQ is done.
2. As others have mentioned, if you have interrupts disabled, the scheduler cannot be invoked periodically by the hardware again. I’m not sure what happens next. Maybe each subsequent task will have to run to completion before the next one is picked up, if it ever completes.

Answer 2

You can't sleep in interrupt handlers in Linux because they are not backed by a thread of execution. In other words, they aren't schedulable entities.

Most systems break interrupt processing into two halves, commonly called a top half and a bottom half. The top half runs very quickly, interrupting (and in fact running as) whatever was executing when the interrupt occurred-the top half has no thread itself. Consequently, the top half is unable to sleep, as there isn't anything to schedule back into when the sleep completes.

From Robert Love on Quora

Answer 3

when interrupt occur, the processor gets into an exception state (Interrupt context). while this happens the scheduler is disabled until the processor exit this state. if you put a task into sleep, the task get into wait queue and tell the scheduler to dequeue another task. if it happens in interrupt context, there is no scheduler until we finish this context and the processor hangs because we never finished the interrupt. what happens exactly is processor depended. one solution for that is to run the actual interrupt code in thread - this is called threaded interrupts and this is one of the configuration in the real-time patch to make linux "hard real time"