Interrupt Handlers

• Interrupt handlers are best hidden
  • Can execute at almost any time
  • Raise (complex) concurrency issues in the kernel
  • Have similar problems within applications if interrupts are propagated to user-level code (via signals, upcalls).
  • Generally, have driver starting an I/O operation block until interrupt notifies of completion; Example dev_read() waits on semaphore that the interrupt handler signals
• Interrupt procedure does its task then unblocks driver that started it
• Steps must be performed in software upon occurance of an interrupt
  • Save registers not already saved by hardware interrupt mechanism
  • Set up context (address space) for interrupt service procedure
    • Typically, handler runs in the context of the currently running process; No expensive context switch
  • Set up stack for interrupt service procedure
    • Handler usually runs on the kernel stack of current process
    • Implies handler cannot block as the unlucky current process will also be blocked $\Rightarrow$ might cause deadlock
  • Ack/Mask interrupt controller, reenable other interrupts
  • Run interrupt service procedure
    • Acknowledges interrupt at device level
    • Figures out what caused the interrupt; Received a network packet, disk read finished, UART transmit queue empty
    • If needed, it signals blocked device driver
  • In some cases, will have woken up a higher priority blocked thread
    • Choose newly woken thread to schedule next.
    • Set up MMU context for process to run next
  • Load new/original process' registers
  • Start running the new process