Interrupt Handler

Interrupt handler
From Wikipedia, the free encyclopedia

(Redirected from Interrupt service routine)
An interrupt handler, also known as an interrupt service routine (ISR), is a callback subroutine in an
operating system or device driver whose execution is triggered by the reception of an interrupt. Interrupt
handlers have a multitude of functions, which vary based on the reason the interrupt was generated and the
speed at which the interrupt handler completes its task.
An interrupt handler is a low-level counterpart of event handlers. These handlers are initiated by either
hardware interrupts or interrupt instructions in software, and are used for servicing hardware devices and
transitions between protected modes of operation such as system calls.
Contents
1 Overview
2 Interrupt threads
3 Symbian OS
4 See also
Overview
In several operating systems - Linux, Microsoft Windows, and some other operating systems in the past,
interrupt handlers are divided into two parts: the First-Level Interrupt Handler (FLIH) and the
Second-Level Interrupt Handlers (SLIH). FLIHs are also known as hard interrupt handlers or fast
interrupt handlers, and SLIHs are also known as slow/soft interrupt handlers, Deferred Procedure Call.
A FLIH implements at minimum platform-specific interrupt handling similarly to interrupt routines. In
response to an interrupt, there is a context switch, and the code for the interrupt is loaded and executed. The
job of a FLIH is to quickly service the interrupt, or to record platform-specific critical information which is
only available at the time of the interrupt, and schedule the execution of a SLIH for further long-lived
interrupt handling.
FLIHs cause jitter in process execution. FLIHs also mask interrupts. Reducing the jitter is most important for
real-time operating systems, since they must maintain a guarantee that execution of specific code will
complete within an agreed amount of time. To reduce jitter and to reduce the potential for losing data from
masked interrupts, programmers attempt to minimize the execution time of a FLIH, moving as much as
possible to the SLIH. With the speed of modern computers, FLIHs may implement all device and platform-
dependent handling, and use a SLIH for further platform-independent long-lived handling.
FLIHs which service hardware typically mask their associated interrupt (or keep it masked as the case may
be) until they complete their execution. An (unusual) FLIH which unmasks its associated interrupt before it
completes is called a reentrant interrupt handler. Reentrant interrupt handlers might cause a stack overflow
from multiple preemptions by the same interrupt vector, and so they are usually avoided. In a priority
interrupt system, the FLIH also (briefly) masks other interrupts of equal or lesser priority.
A SLIH completes long interrupt processing tasks similarly to a process. SLIHs either have a dedicated kernel
thread for each handler, or are executed by a pool of kernel worker threads. These threads sit on a run queue
in the operating system until processor time is available for them to perform processing for the interrupt.
SLIHs may have a long-lived execution time, and thus are typically scheduled similarly to threads and
Interrupt handler - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Interrupt_service_routine
1 of 2 29/3/2011 2:09 PM
processes.
In Linux, FLIHs are called upper half, and SLIHs are called lower half or bottom half. This is different from
naming used in other Unix-like systems, where both are a part of bottom half.
Interrupt threads
Several operating systems - Solaris, NetBSD, Mac OS X, WinCE and FreeBSD, for example - use different
scheme known as interrupt threads. An interrupt handler provided by the device driver is just a high-priority
thread which runs with interrupts enabled and, more importantly, may block on mutex. This greatly simplifies
locking in the kernel. In addition, an interrupt thread may be preempted by some higher-priority interrupt
thread.
Symbian OS
Due to (amongst other reasons) extended processing in a ISR delays the servicing of other interrupts,
Symbian OS uses Delayed Function Calls (DFCs) to perform processing that would be impossible inside the
ISR [1] (http://developer.symbian.com/main/downloads/papers/HWinterupt/HwInterrupt.pdf) .
See also
Advanced Programmable Interrupt Controller (APIC)
Inter-processor interrupt (IPI)
Interrupt
Interrupt latency
Non-maskable interrupt (NMI)
Programmable Interrupt Controller (PIC)
Retrieved from "http://en.wikipedia.org/wiki/Interrupt_handler"
Categories: Interrupts | Operating system technology
This page was last modified on 11 March 2011 at 19:55.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may
apply. See Terms of Use for details.
Wikipedia is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Interrupt handler - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Interrupt_service_routine
2 of 2 29/3/2011 2:09 PM

Interrupt Handler

Uploaded by

Copyright:

Available Formats

Interrupt Handler

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Interrupt Handler

Uploaded by

Copyright:

Available Formats

Interrupt handler

From Wikipedia, the free encyclopedia

You might also like