signal auf raft thread

Volltext

(1)Lehrstuhl für Connected Mobility Fakultät für Informatik Technische Universität München. Grundlagen - Betriebssysteme und Systemsoftware IN0009, WiSe 2020/21 Übungsblatt 4 23. November–29. November 2020 Hinweis: Mit * gekennzeichnete Teilaufgaben sind ohne Lösung vorhergehender Teilaufgaben lösbar.. Aufgabe 1. Windows-Scheduling. Windows setzt eine präemptive Priority Schedulingstrategie mit 32 Prioritäten ein (wobei 31 die höchste Priorität ist). Dabei verwaltet das Betriebssystem eine Liste mit rechenwilligen Threads für jede Priorität und setzt die Round-Robin Schedulingstrategie innerhalb einer Priorität ein. Die Priorität eines Threads setzt sich aus der Priority Class des Prozesses (Real-time, High, Above normal, etc.) und aus der Thread Priority (Time Critical, Highest, Above normal, etc.), die jedem Thread im Prozess individuell zugeordnet werden kann, zusammen. Die Priority Class und Thread Priority bestimmen wiederum die Base-Priority des Threads. Diese wird auf die Prioritäten 0-31 gemapped (siehe Abbildung 1). Dabei sind die Prioritäten 0-15 für non-realtime Benutzerprozesse und die Prioritäten 16-31 für realtime Systemprozesse vorgesehen.. Abbildung 1: Prioritäten unter Windows [Tan15]. Bestimmte Ereignisse führen dazu, dass die aktuelle Priorität eines Threads kurzzeitig (für wenige Quanten) erhöht wird (boost). Dies geschieht zum Beispiel wenn eine I/O Operation fertig wird. Dabei wird jedoch die Priorität von 15 nicht überschritten. Die Base-Priority wird nie unterschritten. Beantworten Sie folgende Fragen zum Windows Scheduling. Nehmen Sie dazu an, dass das Betriebssystem ein Zeitquantum q = 20 ms verwendet. a)* Nennen Sie 3 Möglichkeiten, wie ein multi-threaded Prozess beendet werden kann (aktiv oder passiv).. dei Main thread terminiert Oder der lette Thread terminiert 2 Ein beliebiger thread raft exit l auf wird von einem signal beeudet 3 Der prore 2 B stateRM SIGKILL man signal. 1. b)* Abbildung 2 stellt eine Situation dar, in der das System als nächstes einen Thread mit der Priorität von 26 schedulen möchte. Nehmen Sie an, dass jeder Thread eine Rechenzeit von einem Quantum benötigt und es Prof. Dr.-Ing. Jörg Ott ott@in.tum.de. Martin Uhl gbs@cm.in.tum.de. q 20ms 1.

(2) Lehrstuhl für Connected Mobility Fakultät für Informatik Technische Universität München. keine neuen Threads mit einer höheren Priorität als 3 hinzukommen werden. Wann wird ein Thread mit Priorität 3 in der dargestellten Situation unter Windows laufen können?. RR. I. never. Process. v. µ. Abbildung 2: Scheduling unter Windows [Tan15]. nach 12 q. 12 20ms. 240ms. 2291 Kontextwechsel c)* Nehmen Sie an, dass das Quantum auf 20 ms gesetzt sei und dass der momentane Thread (Priorität 24) gerade ein Quantum begonnen hat. Plötzlich wird eine I/O-Operation fertig und ein Thread mit Priorität 28 wird in den Zustand ready versetzt. Wie lange wird es ungefähr dauern, bis er dran ist?. Die Zeit eines. kontextwechse.is. fans. tabelle Abbitdungi. d)* In Windows ist die momentane Priorität (Current Priority ‚ = Base-Priority + Boost) immer größer oder gleich der Base-Priority. Sind Umstände denkbar, in denen die momentane Priorität kleiner als die Base-Priority gesetzt werden könnte? Geben Sie ggf. ein Beispiel an.. Ein negatives Boost client als Bestrafang fir threads die riel CPU verbrancht haben Prof. Dr.-Ing. Jörg Ott ott@in.tum.de. Martin Uhl gbs@cm.in.tum.de. 2.

(3) Lehrstuhl für Connected Mobility Fakultät für Informatik Technische Universität München. Quellen: [ Tan15 ] Tanenbaum, Andrew S., and Herbert Bos. Modern operating systems. Pearson, 2015. Prof. Dr.-Ing. Jörg Ott ott@in.tum.de. Martin Uhl gbs@cm.in.tum.de. 3.

(4) Lehrstuhl für Connected Mobility Fakultät für Informatik Technische Universität München. Aufgabe 2. Prozessverwaltung und Scheduling. Gegeben seien zwei Prozesse P1 und P2 mit einer in der folgenden Tabelle vorgegebenen Anzahl an KernelLevel-Threads Ki und User-Level-Threads Uj . Die folgende Tabelle gibt sowohl die Startzeit als auch die Rechenzeit für alle Prozesse und Threads an. Prozess P1 P1 P1 P2 P2 P2. Thread K1 K2 K3 U1 U2 U3. Startzeit 0 3 20 2 9 12. Rechenzeit 13 3 2 8 5 4. Pi. Pz. lkernetlevel. Der Kernel-Scheduler arbeitet nach dem Round-Robin Verfahren (Zeitscheiben), wobei eine Zeitscheibe fünf Einheiten beträgt (Aktivitäten des Schedulers oder Dispatchers nicht mitgerechnet). Der Kernel-Scheduler behandelt alle von ihm verwalteten Prozesse und Threads gleich. Sie werden in der Reihenfolge ihrer Startzeit abgearbeitet. Jedes Mal, wenn der Kernel-Scheduler aktiv wird, benötigt er eine Zeiteinheit. Muss zusätzlich ein ProzessKontextwechsel durchgeführt werden, kostet das eine zweite Zeiteinheit. Beachten Sie, dass die initiale Aktivität des Kernel-Schedulers im Diagramm unten nicht berücksichtigt wird und der erste Prozess zum Zeitpunkt 0 direkt mit der Ausführung beginnt. Der User-Level-Scheduler läuft unabhängig vom Kernel-Scheduler. Gehen Sie davon aus, dass jeder Thread nach zwei Zeiteinheiten oder beim Terminieren die Kontrolle an den User-Level-Scheduler abgibt.. sched reihenfolge.de. Der User-Level-Scheduler verwendet die Round Robin Scheduling Strategie. D.h. wie beim Kernel-Scheduler werden die Threads in der Reihenfolge ihrer Ankunft bearbeitet. Weiterhin startet der User-Level-Scheduler neue Threads sofort: Sobald ein neuer Thread hinzu kommt, gibt der laufende Thread die CPU ab und der neue Thread bekommt sie zugewiesen. Als nächstes ist dann der Thread an der Reihe, der regulär nach dem neuen Thread folgt. Der Aufwand für das User-Level-Scheduling ist vernachlässigbar klein, kostet also in dieser Aufgabe keine Zeiteinheiten.. Skizzieren Sie unter diesen Annahmen den Ablauf der Prozesse/Threads im folgenden Gantt-Diagramm. Markieren Sie die Rechenzeiten mit einem X und die Wartezeiten mit einem -.. kernel Threads. imene Fiere. Prof. Dr.-Ing. Jörg Ott ott@in.tum.de. Martin Uhl gbs@cm.in.tum.de. Reinenfolge der. User level Threads. c. te. e. 4.

(5) 0. 1. 3. 13. 4. 5. 6. 7. 8. 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50. 8. I. P 1, K1. 2. 3. P 1, K3. I. x. 2. Martin Uhl gbs@cm.in.tum.de. P 2, U 2. XX. XX. Sched/Disp. o. è2. i. 2. 4. P 2, U 3. Il. o. 6 5 53. si. P 2, U 1. x. o. 1. P 1, K2. X. XX. XX. X. XX. Il. xp X. Scheduling 0. P 1, K1 P 1, K2 P 1, K3 P 2, U 1 P 2, U 2 P 2, U 3 Sched/Disp. 1. 2. 3. 4. 5. 6. 7. 8. 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50. Lehrstuhl für Connected Mobility Fakultät für Informatik Technische Universität München. Prof. Dr.-Ing. Jörg Ott ott@in.tum.de. Scheduling. 5.

(6)