3

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.

TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130
Sumit Gemini
  • 1,836
  • 1
  • 15
  • 19
  • *system may hang* - Why may? Why do you think this is a possibility? – Ed Heal Mar 25 '16 at 06:56
  • Possible duplicate: http://stackoverflow.com/questions/1053572/why-kernel-code-thread-executing-in-interrupt-context-cannot-sleep, see also https://www.quora.com/Why-cant-you-sleep-in-an-interrupt-handler-in-the-Linux-kernel-Is-this-true-of-all-OS-kernels?share=1 – augurar Mar 25 '16 at 07:05
  • 1
    Why does this have a C tag? It's an OS question:( – Martin James Mar 25 '16 at 08:44

2 Answers2

1

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"

Liran Ben Haim
  • 436
  • 3
  • 10
  • Hi Liran Ben, given link call the scheduler in interrupt context, am very confuse what is a cause of not using sleep. https://www.quora.com/Why-cant-you-sleep-in-an-interrupt-handler-in-the-Linux-kernel-Is-this-true-of-all-OS-kernels – Sumit Gemini Mar 25 '16 at 07:49
  • 1
    An external interrupt handler must not sleep or yield, which rules out calling lock_acquire(), thread_yield(), and many other functions. Sleeping in interrupt context would effectively put the interrupted thread to sleep, too, until the interrupt handler was again scheduled and returned. This would be unfair to the unlucky thread, and it would deadlock if the handler were waiting for the sleeping thread to, e.g., release a lock. https://web.stanford.edu/class/cs140/projects/pintos/pintos_6.html – Sumit Gemini Mar 25 '16 at 08:00
1

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

Community
  • 1
  • 1
msc
  • 33,420
  • 29
  • 119
  • 214
  • HI MSC, still not get the problem. what do you mean by "Backed by a thread", is it referred to interrupted process? Does interrupt handler has task_struct? can we call scheduler in the interrupt context? – Sumit Gemini Mar 25 '16 at 07:43