3.5 Unterbrechungsbehandlung (interrupt handling)

Größe: px

Ab Seite anzeigen:

Download "3.5 Unterbrechungsbehandlung (interrupt handling)"

Jutta Egger
vor 5 Jahren
Abrufe

1 3.5 Unterbrechungsbehandlung (interrupt handling) hat folgende Aufgaben: Zustandsdaten des unterbrochenen Prozesses retten und neuen Kontext für die Behandlung aufsetzen, unterbrechungsspezifische Behandlung veranlassen, dabei eventuell Prozessumschaltung vornehmen, Zustandsdaten des unterbrochenen Prozesses oder eines anderen wiederherstellen und diesen Prozess fortsetzen. bs-3.5 1

2 Die Behandlung ist somit zweistufig: primäre Unterbrechungsbehandlung (first-level interrupt handling) sekundäre Unterbrechungsbehandlung (second-level interrupt handling) bs-3.5 2

3 Weitere Kategorisierung von Behandlungen: Alarme (traps): A1 kurze Systemroutine (z.b. Systemaufruf gettimeofday, durch signal gesetzte Routine aktivieren, ) A2 kurze Systemroutine mit evtl. Prozesswechsel (z.b. Systemaufruf wait) A3 längere Systemaktivität mit E/A-Beteiligung und Prozesswechsel (z.b. Alarm Seitenfehler, Systemaufruf read) bs-3.5 3

4 Eingriffe (interrupts) durch Peripherie: E1 kurze Systemroutine (z.b. Laufzeit aktualisieren nach Zeitgeberunterbechung) E2 längere Systemaktivität mit evtl. Prozesswechsel (z.b. nach Beendigung von Eingabe das Eingabegerät erneut starten und wartenden Prozess aktivieren) E3 lange Systemaktivität mit Prozesswechsel und Beteiligung von blockierendem Systemprozess (z.b. nach beendeter Auslagerung einer Seite Einlagerung einer anderen Seite starten und auf deren Beendigung warten) bs-3.5 4

5 Treiber, Gerätetreiber (device driver) ( 4) ist Code im Betriebssystem, der für Ansteuerung und sekundäre Unterbrechungsbehandlung eines oder mehrerer Peripheriegeräte zuständig ist (siehe oben E1, E2; bei E3 ist ein weiterer Systemprozess beteiligt, der wiederum einen Treiber benutzt) bs-3.5 5

6 Treiber, Gerätetreiber (device driver) ( 4) ist Code im Betriebssystem, der für Ansteuerung und sekundäre Unterbrechungsbehandlung eines oder mehrerer Peripheriegeräte zuständig ist (siehe oben E1, E2; bei E3 ist ein weiterer Systemprozess beteiligt, der wiederum einen Treiber benutzt) Untere Schichten des Betriebssystems detaillierter: Dateiverwaltung Speicherverwaltung Treiber 1 Treiber 2 Treiber Prozessverwaltung + prim. Unterbrechungsbehandlung bs-3.5 6

7 3 Alternativen für die Aktivierung der sekundären Behandlung: Prozedur: Koroutine: benutzt Keller des unterbrochenen Prozesses* (geeignet für Behandlung von Systemaufrufen und Software-Unterbrechungen) benutzt eigenen Keller (geeignet auch für Behandlung von Eingriffen, sofern dabei kein Blockieren erforderlich ist) (System-)Prozess: Behandlung in separatem Prozess (sehr flexibel, darf auch blockieren, aber ungeeignet für harte Echtzeit-Anforderungen) * genauer: BS-Teil eines Keller-Paars (user stack, kernel stack) 7

8 Beispiel für : MINIX auftragsbasiertes System ( client/server lokal ), Treiber-Prozesse ( tasks ), allerdings in gleichem Adressraum wie die Prozessverwaltung (kernel threads) weitere Systemprozesse in eigenen Adressräumen bs-3.5 8

9 Beispiel für : MINIX auftragsbasiertes System ( client/server lokal ), Treiber-Prozesse ( tasks ), allerdings in gleichem Adressraum wie die Prozessverwaltung (kernel threads) weitere Systemprozesse in eigenen Adressräumen Benutzerprozesse Init user1 user2 user Server-Prozesse memory file network..... manager system server Treiber-Prozesse disk tty clock system ethernet..... task task task task task Prozessverwaltung interrupts, processes, inter-process communication bs-3.5 9

10 3.5.1 Unterbrechungssystem Zur Erinnerung: Unterbrechungsarten sind hardwaremäßig durchnumeriert, z.b. beim Intel IA32: 0 divide error... 6 invalid opcode Alarme,... nicht unterdrückbar 14 page fault external interrupts ] Eingriffe, unterdrückbar bs

11 Jeder Unterbrechungsart ist hardwaremäßig am Anfang des Speichers eine Unterbrechungsadresse (interrupt location) zugeordnet mit Inhalt neuer Befehlszähler (PC, IP) neues Prozessorstatuswort (PSW) mit Prozessormodus, Prozessorpriorität, Adressraumangabe,... der vom Betriebssystem beim Hochfahren geeignet eingerichtet wird. Alle diese Zellen bilden den Unterbrechungsvektor (interrupt vector). bs

12 Unterbrechungs-Prioritäten: Jeder Unterbrechungsart ist eine Priorität up zugeordnet, d.i. die Dringlichkeit der Behandlung, z.b. mit abfallender Dringlichkeit 7,6,5,... für Zeitgeber, Festplatten, Netz,..., Tastatur Prozessor-Priorität pp im Prozessorstatuswort kann entsprechende Werte annehmen; der Prozessor kann nur dann unterbrochen werden, wenn up > pp und die Unterbrechung führt der Regel dazu, dass pp auf up hochgesetzt wird. bs

13 Unterbrechungs-Unterdrückung (interrupt disabling) bewirkt, dass das Unterbrechungssignal nicht zu einer Unterbrechung führt. Steuerung über den Prozessorstatus mit verschiedenen Varianten: Prozessor-Priorität spezielles Bit für totale Unterdrückung Bits für verschiedene Unterbrechungsarten (statt Priorität) Unterdrückte Unterbrechungssignale gehen nicht verloren (anstehende Unterbrechung, pending interrupt)! bs

14 Unterbrechung: wenn Unterbrechungssignal eintrifft und nicht unterdrückt wird, wird Unterbrechung ausgelöst: Prozessorstatuswort wird gekellert*, Befehlszähler wird gekellert*, neues Prozessorstatuswort wird aus Unterbrechungsvektor geladen (impliziert i.a. Adressraumwechsel), neuer Befehlszähler wird aus Unterbrechungsvektor geladen Unerwarteter (impliziter) Prozeduraufruf Unterprogrammsprung JSR, CALL o.ä. + Austausch des Prozessorstatusworts * vorzugsweise in speziellen Systemkeller, in diesem Fall mit Umsetzen des Kellerzeigers und Kellern des alten Kellerzeigers 14

15 Rücksprung zur Unterbrechungsstelle nach evtl. Prozesswechsel: eines anderen Prozesses! explizit mit Befehl RTI, IRET o.ä.: Befehlszähler wird ausgekellert; Prozessorstatuswort wird ausgekellert, dies bewirkt einen Rücksprung nach vorheriger Wiederherstellung des früheren Prozessorstatus. bs

16 3.5.2 Einfache Unterbrechungsbehandlung am Beispiel Zeitgeber, mit vereinfachender Voraussetzung: wird nur für Zeitscheibenverfahren und Messung der Laufzeiten eingesetzt Charakteristika: Priorität ist hoch Behandlung ist kurz Behandlung beinhaltet keine Sonderfälle rechtfertigt koroutinenartige Behandlung mit Systemkeller bei vollständiger Unterbrechungs-Unterdrückung bs

17 Belegung der Unterbrechungsadresse im Unterbrechungsvektor: Prozessorstatus: totale Unterbrechungsunterdrückung Befehlszähler: verweist auf primäre Behandlung : 1. PSW/PC/SP aus Keller in aktuellen Prozessdeskriptor retten; 2. übrige Register in aktuellen Prozessdeskriptor retten; sekundäre Behandlung - dabei evtl. neuen aktuellen Prozess bestimmen; 3. SP/PC/PSW des aktuellen Prozesses kellern; 4. übrige Register des aktuellen Prozesses laden; 5. Befehl IRET/RTI. (GELB ist Assembler!) bs

18 sekundäre Behandlung: static void timesliceend() { readylist.add(current); dispatch(); } - genau wie in 3.2.1, aber mit anderem dispatch, das nicht mehr für das Umschalten des Prozessors verantwortlich ist: das switch entfällt - zugunsten von ! Rückblick zeigt: war eine rein prozedurale Lösung. bs

19 Alternative: sekundäre Behandlung durch Systemprozess allerdings im gleichen Adressraum (schnelle Erreichbarkeit der Prozessverwaltung!); gerechtfertigt, wenn Zeitverwaltung mehr Aufgaben umfasst (was üblich ist!); Unterbrechung wird umgewandelt in V-Operation oder Auftragsnachricht: bs

20 Mit Systemkeller (S. 17) wird jetzt Auftragsnachricht an Zeitgeber-Treiber versendet. Treiber wird damit aufgeweckt und wird wegen höchster Priorität zum aktuellen Prozess, und die primäre Behandlung wird mit 5 beendet; Treiber rearrangiert die Bereitliste und blockiert in der Empfangsoperation für den nächsten Auftrag; dies geschieht mit erneuter Unterbrechung (über SVC/TRAP) in der Prozessverwaltung ( ), die daraufhin den nächsten Prozess aktiviert.... so realisiert in MINIX: clock task bs

21 3.5.3 Behandlung von Geräteunterbrechungen könnte prinzipiell ebenfalls mit vollständiger Unterbrechungsunterdrückung erfolgen besser aber ist: sekundäre Unterbrechungsbehandlung kann zugunsten höher priorisierter Unterbrechung unterbrochen werden. Falls sonst Behandlung in separatem Treiber-Prozess, dann mit jeweils passender Prozessor- und Prozess-Priorität, Behandlung mit einem oder mehreren Systemkellern, unabhängig von den Kellern der Prozesse, mit jeweils passender Prozessor-Priorität. bs

22 Zur Erinnerung: wenn Daten der Prozessverwaltung manipuliert werden, müssen alle Unterbrechungen unterdrückt werden! Das erfordert erweiterte Funktionalität von DISABLE_INTERRUPTS: ENABLE_INTERRUPTS: rettet aktuelle Prozessorpriorität stellt diese Priorität wieder her bs

23 3.5.4 Behandlung von Alarmen prozedurale Aktivierung genügt über weite Strecken beliebig unterbrechbar (niedrigste Prozessor-Pr.) kurzfristige Unterbrechungsunterdrückung für das Sperren gemeinsamer Daten: - zentrale Daten (z.b. Prozessverwaltung) - Treiber-Daten (bei E/A-Systemaufruf) bs

Ähnliche Dokumente

3.2 Prozessumschaltung

3.2 Prozessumschaltung (dispatching) deaktiviert einen Prozess und aktiviert einen anderen. Wann? aktiver Prozess wird vom Prozessor verdrängt zugunsten eines bereiten Prozesses aktiver Prozess blockiert,