Betriebssystembau (BSB)

Transkript

1 Betriebssystembau (BSB) 6. Übung Olaf Spinczyk AG Eingebettete System Informatik 12, TU Dortmund

2 Agenda Vorstellung Aufgabe 6 Idle-Loop, considered harmful Fadensynchronisation ohne Blockierung Nachtrag Vorlesung: BS-Architekturen Betriebssystembau: 6. Übung 2

3 Agenda Vorstellung Aufgabe 6 Idle-Loop, considered harmful Fadensynchronisation ohne Blockierung Nachtrag Vorlesung: BS-Architekturen Betriebssystembau: 6. Übung 3

4 Aufgabe 6: Die Kunst des Wartens Betriebssystembau: 6. Übung 4

5 Aufgabe 6 Entrant Customer können auf bestimmte Ereignisse warten Jedem Ereignis ist ein Waitingroom zugeordnet Threads, die auf ein Ereignis warten, landen in dessen Waitingroom Warteobjekte sind Waitingrooms und können Ereignisse auslösen Scheduler Organizer kann einen Thread schlafen legen (Readylist Waitingroom) block(thread &, Waitingroom &) und ihn wieder aufwecken (Waitingroom Readylist) wakeup(thread &) Ereignisse in OOStuBS Semaphore V() und Faden wartet Der Tastaturpuffer wurde wieder gefüllt Eine bestimmte Zeit ist vergangen Betriebssystembau: 6. Übung 5

6 Warteobjekt Semaphore Leitet von Waitingroom ab p() Wenn == 0: Warten auf v() (wait) mit Hilfe des Organizers Sonst: um 1 erniedrigen v() Wenn Faden wartet: Ereignis signalisieren (signal) wartenden Thread wecken Was passiert, wenn mehrere Threads gewartet haben? Sonst: um 1 erhöhen Betriebssystembau: 6. Übung 6

7 Warteobjekt Keyboard Idee: anderweitige Nutzung der CPU, wenn auf I/O gewartet wird Thread liest von der Tastatur getkey() des Tastaturtreibers liefert Tasten solange welche im Tastaturpuffer sind wenn Tastaturpuffer leer ist: Thread legt sich schlafen wartet auf Ereignis Tastaturpuffer wieder gefüllt (wait) Signalisierung dieses Ereignisses (signal) Tastatur-Interrupt Epilog, wg. Zugriff aus Thread-Ebene Implementierung Semaphore, die Tasten im Tastaturpuffer zählt Betriebssystembau: 6. Übung 7

8 Warteobjekt Buzzer der Buzzer ist ein Wecker Mit sleep() können sich Threads selbst schlafen legen und warten bis dieser Wecker klingelt Nach einer mit set() gewählten Zeit werden in run_down() wartende Threads geweckt ist abgeleitet von Bell besitzt einen Zähler, der mit tick() runtergezählt wird bei dessen Ablauf wird run_down() aufgerufen der Bellringer Verwaltet Bell-Objekte prüft regelmäßig, ob diese abgelaufen sind und läutet sie ggf. Implementierung: ohne Umweg über Semaphore direkt mit Waitingroom und Organizer (warum?) Betriebssystembau: 6. Übung 8

9 Warteobjekte in OOStuBS Warteobjekte sind Teil des Kernzustands Keyboard und Buzzer signalisieren Ereignisse im Epilog Darf im Epilog auch auf Ereignisse gewartet werden? Semaphore (warum?) müssen daher auf Epilogebene liegen Guarded_Semaphore Guarded_Buzzer Guarded_Keyboard Betriebssystembau: 6. Übung 9

10 Agenda Vorstellung Aufgabe 6 Idle-Loop, considered harmful Fadensynchronisation ohne Blockierung Nachtrag Vorlesung: BS-Architekturen Betriebssystembau: 6. Übung 10

11 Idling Alle Threads, bis auf einen, warten auf ein Ereignis. Nun legt sich dieser auch schlafen. Was jetzt? aktives Warten bis wieder ein Thread bereit ist? wenigstens bleibt die CPU dann schön warm... Lösung cpu.idle() führt wie cpu.halt() eine hlt-instrution aus, erlaubt allerdings vorher Unterbrechungen, anstatt sie zu sperren Tritt eine Unterbrechung auf, wird diese behandelt, anschließend setzt die CPU die Ausführung mit der Instruktion nach dem letzten hlt fort und dann? while (!(next=readylist.dequeue()) cpu.idle(); Ganz so einfach ist es leider nicht! Betriebssystembau: 6. Übung 11

12 Agenda Vorstellung Aufgabe 6 Idle-Loop, considered harmful Fadensynchronisation ohne Blockierung Nachtrag Vorlesung: BS-Architekturen Betriebssystembau: 6. Übung 12

13 Fadensynchronisation: Annahmen Fäden können unvorhersehbar verdrängt werden zu jeder Zeit (auch durch externe Ereignisse) Unterbrechungen von beliebigen anderen Fäden höherer, gleicher oder niedrigerer Priorität (Fortschrittsgarantie) Annahmen sind typisch für Arbeitsplatzrechner probabilistic, interactive, preemptive, online CPU scheduling andere Arten des Schedulings werden hier nicht betrachtet Es ist vor allem die Fortschrittsgarantie, die uns das Leben schwer macht. In rein prioritätengesteuerten Systemen, in denen die Fäden innerhalb einer Prioritätsstufe sequentiell abgearbeitet werden, könnten wir das Prioritätsebenenmodell der Unterbrechungsbehandlung einfach auf Fadenprioritäten ausdehnen und mit vergleichbaren Mechanismen (expliziter Ebenenwechsel, algorithmisch) synchronisieren ( ereignisgesteuerte Echtzeitsysteme) Betriebssystembau: 6. Übung 13

14 Warum eigentlich der Fadenquatsch? Angenommen wir brauchen keine Fortschrittsgarantie Mehrere Anwendungsebenen Statt Fäden ein Kontrollfluss pro Ebene Bräuchten wir dann noch Koroutinen? Was können wir ohne sie nicht? Beispiel: OSEK anstatt Semaphoren oder Mutexes sogenannte Ressourcen Synchronisation ohne Blockieren Betriebssystembau: 6. Übung 14

15 OSEK-OS: Resource Management (1) Synchronisation beim Zugriff auf gemeinsam benutzte Ressourcen, z.b. globale Variablen, E/A-Geräte,... Vermeidet bekannte Probleme von Semaphoren: Semaphor Task R A B C S D T E F U V W G Prioritätsumkehr Da T4 den Semaphor hält, verzögern T2 und T3, die nichts mit dem Semaphor zu tun haben, indirekt den höherprioren T1, da T4 den Semaphor hält, aber noch nicht weiterlaufen kann. Verklemmung Es tritt ein Zyklus im Betriebsmittelbelegungsgraphen auf. Kein beteiligter Task läuft mehr Betriebssystembau: 6. Übung 15

16 OSEK-OS: Resource Management (2) Das OSEK Priority Ceiling Protocol Jede Resource erhält statisch eine Ceiling Priority: Maximum der Prioritäten der Tasks, die auf die Resource zugreifen Wenn ein Task eine Resource anfordert, wird sein Priorität auf die Ceiling Priority gehoben. Zu einer Blockierung kann es dabei nicht kommen. Nach Freigabe der Resource wird die ursprüngliche Priorität wieder hergestellt. 'GetResource' ist nicht blockierend. Damit kann es nicht zur Verklemmung kommen. Solange T4 die Resource hält, kann er nicht von T2 oder T3 verdrängt werden. So wird Priority Inversion Betriebssystembau: 6. Übung vermieden. 16

17 Agenda Vorstellung Aufgabe 6 Idle-Loop, considered harmful Fadensynchronisation ohne Blockierung Nachtrag Vorlesung: BS-Architekturen Betriebssystembau: 6. Übung 17