Unterbrechungsanforderung

Ein Interrupt Request (IRQ) bzw. eine Unterbrechungsanforderung löst eine Unterbrechung eines Prozessors im System aus, in der Regel ausgehend von Geräten im System. Der Prozessor unterbricht daraufhin seine derzeitige Aufgabe und führt die Unterbrechungsroutine aus. Danach wird die unterbrochene Aufgabe fortgesetzt. Eine Alternative Methode zu diesem Zweck ist das Polling,

Beispielsweise generiert die Tastatur einen Interrupt Request, wenn der Benutzer eine Taste gedrückt hat. Die Unterbrechungsroutine kann nun das jeweilige Zeichen von der Tastatursteuerung lesen und es an die jeweilige Anwendung weiterleiten.
Weitere Beispiele, in denen Geräte einen Interrupt Request generieren können:

Netzwerkkarte: wenn Daten empfangen wurden und im Puffer bereitliegen
Festplatte: wenn die vorher angeforderten Daten gelesen wurden und abholbereit sind (das Lesen von der Festplatte dauert relativ lange)
Grafikkarte: wenn das aktuelle Bild fertig gezeichnet wurde
Soundkarte: wenn wieder Sound-Daten zum Abspielen benötigt werden, bevor der Puffer leer wird.

Interrupts und Polling

Interrupts ermöglichen das effiziente Reagieren auf Ereignisse. Die CPU kann unabhängig von den Geräten den Programmcode abarbeiten, wird beim Eintreffen eines Ereignisses unterbrochen, behandelt es entsprechend, und führt die unterbrochene Aufgabe fort.

Die Alternative, in einer Schleife auf das Ereignis zu warten oder regelmäßig ein Gerät nach einem bestimmten Ereignis abzufragen (Polling), benötigt sehr viel mehr Prozessor-Zeit, da ein großer Teil der Abfragen negative Ergebnisse liefern wird. Diese Methode wird jedoch in Systemen verwendet, die sehr zeitkritische Ereignisse behandeln. Dazu werden alle Unterbrechungen unterbunden, da sonst andere, weniger wichtige Geräte durch Unterbrechungen eine Verzögerung hervorrufen könnten.

Die Standard-Analogie für Interrupts im Alltag ist eine Tür mit Klingel: Während man seine Aufgaben erledigt, kann man jederzeit durch die Klingel unterbrochen werden, wenn ein Gast eine „Abarbeitung“ wünscht, und sich ihm dann zuwenden. Beim Polling – also ohne Klingel – müsste ständig an die Tür gelaufen werden, um nachzuschauen, ob Besuch da ist oder nicht.

Funktionsweise

Die an die CPU angeschlossene Hardware muss interruptfähig sein, d. h. bei Eintreffen eines bestimmten Ereignisses ein Ausgangssignal (elektrische Spannung an einem Ausgangs-Pin) erzeugen. Die CPU besitzt im einfachsten Falle einen entsprechenden Eingangs-Pin. Erscheint an diesem Pin eine elektrische Spannung, so startet innerhalb der CPU eine Sequenz von Befehlen, die die Unterbrechungsroutine (Interrupt Service Routine, kurz ISR) einleiten. In einfachen Implementierungen wird nur der gegenwärtige Zustand einiger interner CPU-Register auf dem Stack gesichert, die zur Fortführung des unterbrochenen Programmflusses nötig sind. Dann wird eine Sprungadresse geladen und ein Sprung in die ISR ausgeführt. Der Maschinencode der ISR wird vom Betriebssystem und den Treibern der Geräte installiert. Die Adressen der Unterbrechungsroutinen für alle IRQs befinden sich in der Interruptvektortabelle.

Interrupts können zeitweise von der CPU ignoriert werden, zum Beispiel wenn gerade ein IRQ behandelt wird. Diese Maskierung gilt für alle Interrupts bis auf die nicht maskierbaren (NMI: Non Maskable Interrupt), die für spezielle Fälle vorgesehen sind (Hardware Fehler, Reset usw.), und für die so genannten Software-Interrupts, die durch einen Befehl in einem Programm ausgelöst werden (z. B. 'int IRQNUMMER' bei x86 – dieser Befehl wird beispielsweise von Linux genutzt, um von normalen Anwendungen über Systemaufrufe (syscalls) in den Kernel-Modus zu wechseln).

Latenzzeit

Die Zeit zwischen dem Anlegen des IRQ-Signals und dem Beginn der entsprechenden Verarbeitung nennt man Latenzzeit. Man spricht im Zusammenhang mit Realtime- oder Echtzeit-Betriebssystem davon, dass diese Latenzzeit immer kleiner als ein definierter Wert bleibt – also auch, wenn das System voll ausgelastet ist.

IBM-kompatible PCs

Die Interrupt Requests der Geräte werden zuerst vom Programmable Interrupt Controller entgegengenommen, der sie dann an einen Prozessor weiterleitet, und ihn damit unterbricht. Laufende Befehle werden daraufhin beendet, und der Interrupt wird beim Controller bestätigt. Als nächstes liest die CPU die Nummer des entsprechenden IRQ (Vektor) vom Controller, und verwendet ihn als Index in der Interruptvektortabelle, welche die jeweilige Behandlungsroutine für jeden IRQ enthält, die dann die entsprechenden gerätespezifische Aktion durchführen soll.

Bei modernen Systemen (zum Beispiel PCI-Systemen) ist das so genannte Interrupt-Sharing in der Regel ohne Probleme möglich. Dabei teilen sich mehrere Geräte einen Interrupt. Die Behandlungsroutine für einen solchen Interrupt muss dann alle Treiber, deren Geräte diesen Interrupt ausgelöst haben könnten, aufrufen (am IRQ kann dies nicht festgestellt werden). Hier kann es zu Problemen kommen, wenn einzelne Treiber z. B. aufgrund schlechter Programmierung zu lange aktiv sind, und in der Zwischenzeit im Gerät, welches den Interrupt ursprünglich ausgelöst hat, beispielsweise der Puffer voll wird und überläuft (d. h. im schlimmsten Fall: Datenverlust).

Bei modernen Peripheriegeräten kümmern sich der Computer und das Betriebssystem selbst um die Vergabe der IRQ-Nummern (PnP = Plug-and-Play-Geräte). Bei alten Steckkarten, z. B. ISA-Karten, müssen die IRQs von Hand eingestellt werden oder sind fest auf den Karten verdrahtet.

Unter Linux kann man die Interrupts mit folgendem Befehl abfragen: cat /proc/interrupts

IRQ-Geräte-Tabelle (Diese Liste unterscheidet sich von System zu System)

IRQ	Verwendung
0	System-Taktgeber
1	Tastatur
2	Kaskadiert zu IRQ 9 (für 8-15)
3	COM 2,4,6,8 (EIA-232/RS-232)
4	COM 1,3,5,7
5	Frei ggf. LPT 2 (IEEE 1284)
6	Floppy Disk
7	LPT 1
8	Echtzeituhr (RTC)
9	Zu IRQ 2 umgeleitet (aber auch VGA und NIC, IRQ 16 - 23])
10	Frei ggf. PCI-Bus
11	Frei ggf. Adaptec-SCSI
12	PS/2
13	Mathematischer Coprozessor (FPU)
14	Primary IDE
15	Secondary IDE

Weblinks