bzw. 7. Nebenläufigkeit

Transkript

1 7. Nebenläufigkeit 7.1 Terminologie Thread: - In einer bestimmten Reihenfolge (sequentiell) auszuführende Folge von Instruktionen, - Typischerweise ein Ausführungskeller für Prozeduraufrufe und Rekursion, - Bedingte und unbedingte Sprünge und Verzweigungen (if, case, loop...). bzw. 7-1

2 Parallele Ausführung: - Ziel ist die höhere Rechenleistung, - mit oder ohne Synchronisierungsmöglichkeit, - Gleichzeitiger Ablauf, mehrere Orte der Verarbeitung, - mehrere CPUs oder auch CPU+Geräte, - Wartezeiten sind möglich. - nichtdeterministisch, Nebenläufige Ausführung: - Ziel ist es, Wartezeiten anderweitig zu nutzen, - Umschaltung zwischen Threads => - oder auch paralleler Ablauf, - nichtdeterministisch. Scheduling: - Steuern der Umschaltung zwischen den Threads, - Threadzustände: Ready, Run, Wait - Preemptive, cooperative... CPU1 CPU2 CPU3 Gerät Nur CPU1 7-2

3 Adressraum: Der in einem Zeitpunkt direkt adressierbare Speicher. Programm: statische Darstellung eines Algorithmus. Prozeß: Adreßraum + Thread(s). Task: Aufgabe, die durch einen oder mehrere Prozesse erledigt wird. Light weight process ~ Thread: - separater Registersatz & eigener Laufzeitkeller, - keine Umschaltung des Adressraums erforderlich, - teilt sich Daten, Code & Betriebsmittel, - gehört zu einem Adressraum. IPC: Interprozesskommunikation: - Local Procedure Calls, - Shared Memory, - Pipes, RMI, - oder über Middleware... Prozess N-1 Prozess N IPC 7-3

4 Multithreading: mehrere Threads pro Prozess vorhanden. Multitasking: - Mehrere Tasks (Prozesse, Threads, TAs) werden (scheinbar) gleichzeitig ausgeführt - Preemptive: Betriebssystem kann einem Task jederzeit die CPU entziehen - Cooperative: Threads müssen den Prozessor freiwillig freigeben Transaktions-Schleife in µ-plurix (Cooperative Multitasking): private void Loop( int taindex ) { Transaction currentta; while ( true ) { if ( taindex >= freetaslot ) taindex = 0; // wrap around? currentta = TAVector[ taindex++ ]; if ( currentta.scheduletime <= STATION.ticks ) { currentta.run(); if ( focus!= null ) focus.repaint(); } } }; // Loop, while, if 7-4

5 7.2 Prozeße Anzeige von Prozessen Programm-Name: - Anwendungsprogramme, - Fenstermanager (csrss), - Windows Explorer, - Dienste, System, - Leerlaufprozess. Benutzername. CPU-Verbrauch. Speicherverbrauch. Nicht angezeigt: - Prozess-ID, - Offene Dateien, - Enthaltene Threads. 7-5

6 Klassische Unix-Prozesse: - Ursprünglich keine Threads, - Prozesshierarchie (Vater/Sohn), - eigener Adressraum pro Prozess, - Prozess repräsentiert sequentielle Aktivität, - Nebenläufigkeit durch mehrere Prozesse. Linux Prozesse mit Threads: - Threads als Light-weight P. - pro Prozess mindestens ein Thread, - Nebenläufigkeit durch mehrere Threads. - Thread repräsentiert sequentielle Aktivität. - Prozesse als Adressraumhülle für Threads. Gnome System Monitor (Knoppix)=> Oder PS-Befehl. 7-6

7 7.2.2 Prozesskontrollblock (= process control block (PCB)) Beschreibt einen Prozess im Kontext des Betriebssystemkerns. in Linux als task_struct[ ]: bis 3000 Prozesskontrollblöcke möglich, - pro Prozess oder Thread eine task_struct. Prozess-Identifikation: - Numerische ID für Parent und Prozess selber, User-ID CPU Zustandsinformation: - Sichtbare und unsichtbare Register, CPU Flags. Scheduler Information: - Prozesszustand, Priorität, erwartetes Event. Zeiger auf verwandte Prozesse. IPC: Unix-Signale, Flags und Messages Betriebsmittel: Speicher, Dateien, Zugriffsrechte. 7-7

8 7.2.3 Prozesserzeugung Zwei Arten der Prozesserzeugung: - Kopie des rufenden Prozesses anlegen. int pid; - Aufrufer durch ein neues Programm ersetzen. Neue Prozesse entstehen: - durch einen Befehl, - beim Start des Systems (Dienste), - durch Systemaufruf in einem laufenden Prozeß. Erzeugen von Prozesskopien mit fork: - erzeugt eine Kopie des rufenden Prozesses, - Vater-Sohn Beziehung, - mit neuer PID. neuer Prozess hat eigenen Adressraum: - ältere Unix BS kopieren sofort alle Seiten, - neuere Systeme (z.b. Linux) verwenden einen Copy-On-Write Modus. pid = fork(); if (pid < 0) {/* fork failed */} else if (pid > 0) { /* Vater-Code */ } else { /* Kind-Code */ } 7-8

9 Aufrufer durch ein neues Programm ersetzen: - int execve(char *path, char *const argv[]); - Aufruf kehrt nicht mehr zurück. - rufender Prozess wird ersetzt. - neues Programm übernimmt PID. Problem: - ältere fork Implementierungen kopieren den ganzen Adressraum. - Start neuer Programme ist teuer, falls fork und execve verwendet würden. Lösung: vfork - Kind-Proz. teilt Adressraum mit Vater. - aber Aufrufer wird blockiert, bis Kind execve oder exit ruft. Ablauf beim Erzeugen eines neuen Prozesses: - PCB initialisieren, Prozess-ID festlegen, - Adressraum anlegen bzw. kopieren, - Befehlszeiger auf Startadresse setzen, - Eintrag des PCBs in die Bereit-Warteschlange. Hintergrundprozesse werden in Unix als Daemon bezeichnet (z.b. Spooler). 7-9

10 7.2.4 Neue Prozesse erzeugen in Windows XP mit CreateProcess: keine Kopie des Adressraums. keine Vater-Sohn-Beziehung. Hintergrundprozesse in NT: - implementieren best. Funktionen, - als Dienste (Services) bezeichnet, - Überwacht durch Service Control Manager. main() { STARTUPINFO si; // window stuff PROCESS_INFORMATION pi; // handle } GetStartupInfo(&si); // get some values CreateProcess( MyProg.exe, // program (incl. path), // command line params. NULL, // process security attributes NULL, // thread security attribute FALSE, // handles vererbbar? CREATE_NEW_CONSOLE, NULL, // environment block NULL, // current dir. for new process &si, // startup info. &pi // process info. ); 7-10

11 7.2.5 Prozesshierarchie in Unix Vater-Kind-Beziehung zwischen Prozessen führt zu einer Prozesshierarchie: - Nach erfolgreicher Anmeldung wird Terminal durch shell-prozeß ersetzt. - Beim Start von Unix wird init gestartet. - init erzeugt definierte Anzahl Terminals. - Terminals (getty-proz.) führen login aus. - Bsp.: Linux (Benutzer hat Mail-Prg. aufgerufen) init PID: 1 fork init PID: 28 getty PID: 28 login PID: 28 execve execve execve init PID: 1 bash PID: 28 fork bash PID: 45 bash PID: 28 execve mail PID: 45 mail PID:

12 7.2.6 Beenden von Prozessen Prozess führt letzte Anweisung aus & teilt BS Programmende mit ( exit ). Zombie-Prozess in Unix: - Ein Prozess dessen Exit-Code nicht abgeholt wurde. - Infos über Kind (PCB) werden für Vater-Prozess noch gespeichert. Bem.: terminiert der Vater vor dem Kind, so werden bei Linux die Kinder dem Init-Prozess zugeordnet. In Unix kann Elternprozess kann auf Beendigung eines Kindprozesses inklusive Statusrückgabe warten waitpid oder wait. Evt. abrupt beenden mit kill, mögl. Gründe: - allokierte Ressourcen wurden verbraucht, - Kindprozess wird nicht länger benötigt, - Elternprozess terminiert. NT bietet TerminateProcess(handle,exitcode): - im Prinzip nicht verwendet, da keine Vater-Sohn-Beziehung, - Anwendungen bestehen aus Threads, diese werden bei Prozessende autom. terminiert. 7-12

13 7.2.7 Prozesszustände im klassischen Sinne Prozesszustände (vereinfacht): - blockiert: Prozess wartet auf ein Ereignis (z.b. Ende eines E/As, Signal,...). - beendet: Prozess hat Ausführung abgeschlossen. - bereit: Prozess wartet auf CPU-Zuteilung. - läuft: Prozess wird auf CPU ausgeführt. - neu: Prozess wurde erzeugt. Deblockieren blockiert neu start bereit Für alle Zustandsübergänge sind warten läuft Kernelfunktionen vorhanden: stop - Freigeben: Umschalten auf einen anderen Prozess. Der bisher rechnende Prozess bleibt fortsetzbar. bereit. beendet - Warten: CPU-Freigabe, da Bedingung nicht erfüllt. blockiert. - Zuordnen: Auswahl des nächsten Prozesses aus der Bereit-Liste. läuft. - Deblockieren: Ereignis, auf welches der Prozess gewartet hat tritt ein. bereit. freigeben zuordnen 7-13

14 Beispiel: Prozesszustände in Unix: - UserRunning & KernelRunning: beschreibt, ob P. im Kernel oder User-Mode läuft. - ReadyToRunSwapped: Prozess bereit, aber derzeit komplett auf Disk geswappt. - SleepSwapped: Prozeß wurde ausgelagert, während er auf ein Ereignis wartete. - Preempted & ReadyToRunInMemory: im Prinzip gleicher Zustand; Unterscheid. soll Art u. Weise betonen, wie der Zustand erreicht wird. - Preempted: viele ältere Unix BS erlauben keine Verdrängung im Kern. Preemption nur beim Rücksprung aus dem Kern mögl. Deshalb geht dieser Zustand beim erneuten Zuteilen der CPU immer sofort in User Running über. 7-14

15 7.3 Thread Varianten Threads eines Proz. operieren im selben Adressraum kein HW-Schutz. Wenn möglich Threads anstelle von Prozessen verwenden: - Adressraumübergreifende Komm. ist langsam, deshalb mehrere Th. pro Adressraum. - Wechsel des Prozesskontextes ist teuer (Cache, TLB, MP-Systeme), - Der Start Befehl ist aufwendig, Verwaltung durch Thread-Kontrollblock (=TCB): - Enthält Zustand, wenn der Thread gerade nicht läuft. - C-Text in der Datei include/lt-threads.h - Thread-Identifikation (ID), - Maschinenzustand (Register), - Scheduling Informationen, - Verwaltungsdaten für BS. Typische Einsatzgebiete: - Blockierendes Warten auf Ereignisse (Eingabe...), - Separater Thread für die Benutzerschnittstelle vorsehen, - gleichzeitige Bearbeitung von Einzelaufgaben (Web-Requests...) ID Programmzähler Register Priorität Ausführungszeit 7-15

16 7.3.1 User-Level-Threads Programm ruft API-Funktionen zum Umschalten zwischen Threads. - User-Level-Threads sind dem OS-Kern nicht bekannt, - Umschalten auch bei nicht leerem Stack, Programm - Manipulation durch Thread-Bibliothek, - Entspricht sog. Koroutinen. switch Vorteile: - unabhängig vom unterliegenden BS. - Scheduling in der Hand des Programmierers. - Umschalten sehr schnell - ohne Umweg über OS. Nachteile: - Kein Wechsel des AR bei Thread-Wechsel möglich. switch OS Kernel - Bei einem blockierenden Systemaufruf werden alle Threads blockiert. - Fairnessproblem bei unterschiedl. Thread-Anzahl in den einzelnen Prozessen. Beispiele: - Windows NT Fibers, GNU Portable Threads, JVM Greenthreads

17 7.3.2 Kernel-Level-Threads KL-Threads sind dem Kern bekannt und unterliegen dessen Kontrolle: - Umschaltung zwischen den Threads eines Prozesses geschieht durch den OS-Scheduler, - müssen nicht, können jedoch mit einem Benutzerprozeß verbunden sein, - Umschaltung geschieht auch auch prozessübergreifend, - Kern verwaltet Thread- und Prozeßtabelle. Vorteile: - Keine Blockierung von Threads im selben Prozess, - Scheduling im Gesamtsystem. Nachteile: - Geschwindigkeitsverluste beim Umschalten, - Cache und TLBs müssen, aktualisiert werden, - Evtl. Umschalten ins Betriebsystem und zurück, Beispiele: - Windows NT, Solaris 2, BeOS,... Programm Switch OS Scheduler

18 #include "stdio.h" #include "windows.h" DWORD loop = 500*1000*1000; HANDLE hevent, hchild; DWORD WINAPI Child( LPVOID lpparm ) { while (loop>0) { loop--; }; printf("'child' signalisiert:\n"); SetEvent(hEvent); return 0; } int main(int argc, char* argv[]) { // defaultsecurity, autoreset, nonsignalled, noname hevent =CreateEvent(NULL, 0, 0, NULL); // defaultsecurity, stack, procaddr, tparam, noname hchild =CreateThread(NULL, 8, &Child, &loop, 0, 0); } printf( "'main' wartet auf Signal.\n" ); result =WaitForSingleObject( hevent, INFINITE ); 7-18

19 7.3.3 Hybride Threads Lightweight-Prozesse (LWP): - zur Kommunikation der UL-Threads mit Kern, - Jeder LWP hat einen Kernel-Level Thread, - langsam falls Adressraumwechsel nötig, - Jeder Prozess hat >= 1 LWP. User-Level Threads: - Multiplexen von UL-Threads auf LWPs. - schneller Wechsel ohne Kern-Interaktion. - Mit LWPs verbundene UL-Threads können arbeiten, andere sind blockiert. Kernel-Level Threads: - Dienen der Ausführung der Kern-Operationen. - relativ schnelle Wechsel (nur ein Adressraum), - optional feste Prozessor-Zuordnung. Beispiel: Solaris 2. Prozeß 1 Prozeß 2 Prozeß 3 CPUs Kernel 7-19

20 7.3.4 Threads in Java Die Klasse java.lang.thread: - Vererbt die Methode run( ) => Überschreiben der Methode run(), - Alternative ohne Thread-Vererbung: Thread( Runnable any ). Thread-Methoden: - Warten auf Beendigung: join(); - Verzögern: sleep(); - Abgeben: yield(); - Starten: start();... Deprecated methods: - Unterbrechen: suspend(); - Aufwecken: resume(); - Abbrechen: stop(); Run( ) invoke Runnable Java Virtual Machine bietet evtl.: - Green Threads: emuliert durch JVM-Koroutinen. - Native Threads: abgebildet auf Betriebssystem-Threads. implement Thread extend ExtendingTh AnyClass extend ImplementingRu 7-20

21 7.3.5 Beispiel für Java Threads: Ausgabe entsprechend obigem Bildschirmauszug. public class ExampleThread extends Thread{ static char last; static long count=100*1000*1000+6; char threadname; ExampleThread(char name){ thname =name; } // constructor public void run(){ while (count -- >0) { if ( last!= thname){ last= thname; System.out.print(thName); } } } public static void main( String[] args ) { new ExampleThread('A').start(); new ExampleThread('B').start(); // start will spawn the Thread new ExampleThread('C').start(); // run is only method call! } } 7-21

22 7.3.6 Threads in Windows XP Der OS-Kern in Windoiws XP ist ein Prozess mit mehreren Threads. Job: als Gruppe von Prozeßen (ab Windows 2000). Prozess als Container für Resourcen: - keine Verwandtschaft zwischen Prozessen. Thread als Aktivitätsträger: - Eins-zu-Eins Abbildung von UL- und KL-Threads. - ein oder mehrere Thread(s) pro Prozeß. Fiber als User-Level Thread. Threadzustände in Windows XP: 7-22

23 7.3.7 Threads in Linux Gemeinsame Nutzung der umgebenden Prozess-Ressourcen. User-Level Threads werden durch eine Bibliothek erzeugt: - z.b. GNU Pth (Portable Threads), auch für OS ohne Threads. Lightweight Process als Schedulable Entity. - UL Threads müssen zur Ausführung an einen LWP gebunden werden, - Erst dann können sie vom Kern gescheduled werden, - Vtl. Nicht jederzeit enug LWPs im Kern vorrätig. Kernel-Level Threads (KL): - Ausführen von Kernel-Diensten oder von LWP für User-Levl Threads, - Ohne eigenen Adressraum. clone: erzeugt KL-Thread mit eigener TID: - CLONE_PID: PID übernehmen, - CLONE_VM: share virtual address space, - CLONE_FILES: share open file descriptors, fork: erzeugt einen Kind-Prozeß mit eigenem Adressraum. 7-23

24 #include <sched.h> int thread_proc(void *arg) { /* Endlosschleife */ for(;;) printf("* ); } main() { int thread_stack[4000]; /* Stacks für den Thread */ // int clone(int (*fn)(void*), void *stack, int flgs, void *arg); clone(thread_proc, thread_stack+4000, CLONE_VM, 0); /* Endlosschleife */ for(;;) printf(". ); } 7-24

25 7.4 Prozess- bzw. Threadumschaltung "Multiplexen der CPU/Recheneinheit". Dispatcher: Modul, welches das Umschalten implementiert. Scheduler: Modul, welches die Umschalt-Strategie implementiert. Ablauf der Prozess- bzw. Threadumschaltung: - PCB/TCB sind wichtige OS-Datenstrukturen, - Bearbeitung des aktuellen Threads/Prozesses wird unterbrochen, - Aktuellen Zustand z.b. im aktuellen Task-State Segment (oder dergl.) sichern, - Kontext/Betriebsmittel/Resourcen umschalten (Files, Stack, Tabellen...), - Neuen Zustand in die CPU laden, - Neue Task anstossen. Teuer ist das Umschalten des Adressraumes Caches & TLB spülen. Beschleunigung durch HW-Unterstützung (z.b. Intel Task State Segment). Das Umschalten auf einen Kern-Thread beinhaltet auch einen Moduswechsel vom User- in den Kern-Modus ( Intel Protection Rings). Gründe für Threadwechsel: 7-25 Task A OS Task B

26 - Rechenzeit abgelaufen, - Interrupt von HW & SW, - Warten auf E/A-Operation, - freiwillige Abgabe der CPU. Reentrant BS-Code wichtig: - Nutzung durch parallele Threads. - keine Zustandsinformation in globalen Variablen halten 7-26

27 7.4.1 Umschalttechniken Manuelles Umschalten: - einfachste Umschaltform durch direkten Sprung. - Umschaltzeitpunkt und -ziel im Quelltext. - effizient, aber inflexibel für Echtzeitsysteme. Automatisches Umschalten: - Umschalten an beliebigen Stellen, - aber innerhalb definiertem Zeitintervall, - Interrupts im User-Modus nicht maskierbar. Verwendung des Hardware-Zeitgebers: - CPU wird durch Timer entzogen (Time-Slice). - IRQ-0 für Timer (höchste Interruptpriorität), - Interrupt nach konfig. Periode (typ. 10ms). - verwendet bei preemptiven Multitasking. Bedingtes Umschalten: - Umschalten abhängig von einer Bedingung. - Zum Bsp. wenn E/A-Operation notwendig ist. 7-27

28 7.4.2 Umschaltverhinderung Geräte-Timeout: - erwarten Befehle innnerhalb eines bestimmten Zeitintervalls. kritische Funktionen im Kern: - Umschalten zw. Prozessen, - Enqueue & Dequeue... Einfache Lösung: - Interrupts kurzfristig sperren. Genügt auf MP-Systemen nicht: - zusätzl. Synchronisierung notwendig, - Snooping, Cache & TLB Management, - Signalisierung über APIC, - Atomare Bustransaktionen, 7-28

29 7.5.1 Überblick 7.5 Scheduling (Ablaufplanung) Scheduler: - regelt die Zuteilung der CPU: - wählt nächsten Thread aus der Bereit-Queue. - Anzahl der Threads & Prozesse ändert sich laufend. Unterscheidung zw. Ablaufplanung mit und ohne Verdrängung: - Verdrängung (=Preemption) = Entzug d. CPU. - realisiert mit Hilfe von Zeitgeber-Interrupt. Scheduler tritt in Aktion wenn ein Thread: - startet & terminiert, - freiwillig die CPU freigibt, - auf eine E/A-Operation wartet, - seine Zeitscheibe voll ausgenutzt hat. Threadverhalten ändert sich dynamisch: - rechenintensive Phasen mit ununterbrochener CPU Nutzung und seltenen E/As. - E/A-lastige Zeitabschnitte mit nur kurzen CPU-Nutzungszeiten und häufigen E/As. 7-29

30 7.5.2 Scheduling-Ziele Effizienz: Optimale CPU-Ausnutzung. Bei Bedarf bis 100%. Wartezeit: Wartezeit in der Bereit-Liste minimieren. Fairness: - Jeder Benutzer bzw. Prozess sollte im Mittel den gleichen CPU-Zeitanteil erhalten. Durchsatz: - #Threads pro Zeiteinheit sollte maximal sein, für Stapelsysteme wichtig. Ausführungszeit: - Die Zeitspanne vom Jobbeginn bis zum Jobende sollte sie minimal sein. - Sie enthält alle Zeiten in Warteschlangen, der Ausführung (Bedienzeit) und der E/A. Antwortzeit: - Die Zeit zwischen einer Eingabe und der Übergabe der Antwortdaten an die Ausgabegeräte sollte minimal sein ( interaktive Systeme). Problem: - Ziele teilweise gegenläufig, Overhead beim Umschalten 7-30

31 7.5.3 First Come First Served (FCFS) Bearbeitung der Threads in Reihenfolge ihrer Ankunft in der Bereitliste. Prozessorbesitz bis zum Ende oder freiwilligen Aufgabe. Beispiel: - Laufzeit: t(t1)=24, t(t2)=3, t(t3)=3 T1 - Ankunftsreihenfolge: T1, T2, T3 - Durchschnittl. Wartezeit: ( ) / 3 = 17. T2 T Ankunftsreihenfolge: T2, T3, T1 - durchschnittliche Wartezeit = 3! T2 T3 T Probleme: - Konvoi-Effekt = schnelle Threads stauen sich hinter einem langsamen Thread. - CPU-lastige Threads halten I/O-lastige auf. 7-31

32 7.5.4 Shortest Job First (SJF) Thread mit der kürzesten Bedienzeit wird als nächster bis zum Ende oder freiwilligen Aufgabe bearbeitet. Bedienzeit muss bekannt sein, lang laufende Threads können verhungern. T1 T3 T2 Bevorzugt kurze Threads. Beispiel: - Laufzeit: t(t1)=7, t(t2)=4, t(t3)=1, t(t4)=5 - Ankunftszeiten: at(t1)=0, at(t2)=1, at(t3)=2, at(t4)=3. - non-preemptive: durchschn. Wartezeit = 5,25 - preemptive: durchschnittliche Wartezeit = 3,5 0 T T1 T2 T3 T2 T4 T

33 7.5.5 Round Robin (Zeitscheibenverfahren) Ziel: gleichmäßige Verteilung der CPU. Verbreitete Strategie (z.b. Linux und NT): - Threads in Ankunftsreihenfolge verarbeiten. - Nach Ablauf einer vorher festgesetzten Frist (z.b ms) findet Verdrängung statt. - Einreihung des Threads nach Ablauf der Zeitscheibe (Zeitquantums) am Ende der Bereit-Queue, sofern er nicht blockiert ist. Problem: richtige Wahl der Zeitscheibe: - Vernünftiges Verhältnis zw. Quantum und Kontextwechselzeit notwendig. - Grosse Zeitscheiben sparen Kontextwechsel, verursachen aber lange Antwortzeiten. Beispiel: - Laufzeit: t(t1)=53, t(t2)=17, t(t3)=68, t(t4)=24 - Ankunftszeiten: at(t1)=0, at(t2)=1, at(t3)=2, at(t4)=3. - Zeitscheibe = 20. T1 T2 T3 T4 T1 T3 T4 T1 T3 T

34 7.5.6 Prioritäts-Scheduling Jeder Thread erhält eine Prioritätsnummer. Threads mit der höchsten Priorität wird aus der Bereit-Queue selektiert. Implementierung: mehrere Bereits-Queues: - Vordergrund- und Hintergrundprozesse, - oder für jede Priorität eine Warteschlange. TCBs hohe Priorität niedrige Priorität 7-34

35 Problem Aushungern (Starvation): ein Thread mit niedriger Priorität bekommt die CPU nicht zugeteilt, da immer Threads mit höherer Priorität rechenbereit sind. Lösung: Altern (Aging): Priorität steigt mit der Wartezeit Feedback Scheduling. Bem: SJF ist prioritäts-basiertes Verfahren erwarteter Burst-Zeit als Priorität. Problem: Prioritätsinvertierung 7-35

36 Zustand blockiert wartet auf Thread C Prio=12 Ressource besitzt Thread A Prio=4 Thread B Prio=8 Zustand bereit Zustand rechnend - Thread C verhungert, trotz höchster Priorität. - Thread B dominiert die CPU. - Dadurch kommt Thread A nicht zum Zuge und kann daher die Ressource nicht freigeben. Thread C auf unbestimmte Zeit blockiert. 7-36

37 - Lösung Altern mit der Wartezeit: o Priorität von Thread A steigt langsam an. o Sobald sie >8 ist, löst sich das Problem. - Bem.: War Problem bei Mars Pathfinder, siehe D. Wilner, Vx-Files: What really happened on Mars?, Keynote at the 18th IEEE Real-Time Systems Symposium, Dec Multilevel Scheduling Kombination mehrerer Scheduling-Verfahren. Bereit-Liste wird in Sublisten unterteilt. Pro Subliste eigene Scheduling-Strategie. Scheduling zwischen den Sublisten: - statische Priorität, - Zeitscheiben. Aufträge abh. von gewünschter Betriebsform in die entsprechende Liste einsortieren. 7-37

38 Beispiel: Prio 0: Systemprozesse Prio 1: Interaktive Jobs Prio 2: Allgemeine Jobs Prio 3: Rechenintensive Jobs 7-38

39 7.5.8 Feedback-Scheduling Dynamische Anpassung der Scheduling-Kriterien (z.b. Zeitscheibenlänge, Priorität): - Verhungern verhindern, - Prioritätsinversion auflösen, - Balance zw. E/A- u. rechenintensiven Threads. Lösg.: Berücksichtigung der Warte -Historie eines bereiten Threads. Beispiel: Multilevel-Round-Robin - Verdrängte Threads (benötigen mehr Zeit) in Bereit-Liste mit längerer Zeitscheibe/geringerer Priorität einordnen. - Threads, welche blockierende E/A-Fkt. aufrufen od. CPU freiwillig abgeben, bleiben in Warteschlange E/A-lastige Threads bevorzugen. - Aging Hochstufung bei langem Warten. 7-39

40 Z e i t s c h e i b e 16ms 32ms 64ms 128ms 256ms TCBs hohe Priorität niedrige Priorität 7-40

41 7-41

42 7-42

43 7.5.9 Strategien für Echtzeitsysteme Echtzeitsysteme müssen def. Zeitschranken einhalten, auch in Fehlersituationen. Für krit. Anwendungen (z.b. Kernkraftwerk). Threads erhalten Sollzeitpunkte (Deadlines). - Voraussetzung: Laufzeit vorab bekannt. - Unterscheidung bei Sollzeitpunkten zwischen: o Harter Echtzeit: Verletzung bedeutet Ausfall des Systems (nicht tolerierbar). o Weicher EZ: Qualitätseinbußen bei Verletzung, aber in Grenzen tolerierbar. Keine Desktop-Betriebssysteme, sondern typ. eingebettete Systeme (z.b. OSEK). Offline-Scheduling Scheduling vor der eigentlichen Ausführung zur Vermeidung von Scheduling-Overhead. 7-43

44 Vorberechnung eines vollständigen Ausführungsplans in Tabellenform. Einfacher Tab.zugriff während Ausführung. Sinnvoll für harte Echtzeitanforderung. Earliest Deadline First (EDF) Verbreitete Strategie. Threads mit Ausführungsfristen. Thread mit engster Frist wird bevorzugt. Beispiel: Earliest Deadline First - Laufzeit: t(t1)=4, t(t2)=5, t(t3)=3 - Fristen: f(t1)=10, f(t2)=7, f(t3)=17 - non-preemptive; gleiche Ankunftszeit. T2 T1 T

45 - preemptive: Ankunftszeiten: at(t1)=0, at(t2)=1, at(t3)=2. T1 T2 T1 T Dynamischer Einplanbarkeitstest notwendig, wenn ein neuer Thread hinzukommt. CPU Auslastungsgrenze bis zu 100%. 7-45

46 Rate Monotonic Scheduling (RMS) Zur Beschreibung periodischer Systeme: - hohe Priorität für Aktivitäten mit hoher Freq. - niedrige Prio. für Akt. mit kleiner Frequenz. - Ende der Periode entspricht der Deadline. - z.b. für Multimediaströme. Vor.: Threads sind unabhängig voneinander. Vorteil: min. Verzögerung hochfreq. Akt. Nachteil: - Zerstückelung niederfrequenter Aktivitäten. - Situation, die durch Verzögerung eines höher priorisierten Threads, zu einem gültigen Ablauf führen, sind nicht lösbar. - CPU Auslastungsgrenze nur bis ~70%. Beispiel: - Laufzeit: t(p1)=3, t(p2)=2, t(p3)=1, t(p4)=2, t(p5)=

47 - Periode: p(p1)=13, p(p2)=15, p(p3)=9, p(p4)=16, p(p5)=

48 Mehrprozessor-Aspekte Wahllose CPU-Zuteilung schlecht: - Lastausgleich zwischen CPUs. - Hat Thread t zuletzt Prozessor p genutzt, so besteht die Chance, dass noch Teile seines Adr.raums im Cache von p vorhanden sind. Einführung der Prozessor-Affinität: TCB wird um zuletzt benutzte CPU erweitert. Nachteil: Aufweichung von Prioritäten: - evt. zuletzt genutzte CPU belegt und andere frei - falls auf alte CPU gewartet wird, so läuft evt. ein Thread mit niedriger Priorität zuerst. 7-48

49 Leerlaufproblem Falls alle Threads warten ist die CPU frei. In dieser Zeit läuft ein Leerlauf-Thread: - darf nicht anhalten, - hat geringste Priorität, - muss jederzeit verdrängbar sein. Leerlauf nutzbar für: - Prüfungen, - Garbage Collection, - Heap Kompaktifizierung. 7-49

50 7-50

51 Scheduling in Unix System VR3: Scheduler kennt nur Prozesse, keine Threads. Verdrängendes Feedback-Scheduling: - z.b. pro Priorität eine Queue mit Round Robin. - Scheduler passt Prioritäten von Benutzerprozessen (beginnen z.b. mit n/2) dynamisch an. - Benutzer kann Priorität mit setpriority bzw. nice beeinflussen, aber es gilt Prio User > Prio System. - Beispiel: je kleiner Wert desto größer Priorität: 7-51

52 -m -1 0 Systemprozesse (statische Priorität) n Benutzerprozesse (dynamische Priorität) Kern ist nicht verdrängbar: Proz. der im Kernel-Modus läuft kann erst beim Rücksprung in den User-Modus verdrängt werden. Dynamische Anpassung von Prioritäten: 7-52

53 - für Prozesse in der Bereit-Queue. - jede Sekunde angepasst nach der Formel: dyn_prio := base_prio + cpu_usage / 2 + nice (CPU-Nutzung gemessen in Uhr-Ticks ). - vorher wird schrittweise vergessen, wie groß die Prozessornutzung war: cpu_usage := cpu_usage / 2. - zusätzlich wird alle 40ms dyn_prio des lfd. Prozesses neu berechnet. - Starke CPU-Nutzung führt zu schlechter Prio.: o rechenintensive Proz. werden benachteiligt und I/O-intensive Proz. werden bevorzugt. o I/O-lastige Proz. belegen die CPU nur kurz, um einen E/A-Auftrag abzusetzen. o Man erreicht dadurch eine Balance zw. CPU- und I/O-lastigen Aufgaben. - Blockiert Proz., weil er auf ein Ereignis wartet: o so erhält er abh. vom Ereignis eine höhere Kernel-Priorität. o Beim Übergang v. Kernel- in den User-Mode erhält er wieder seine alte User- Prio. Bem.: Prioritäten, die Benutzer sieht, werden oft auf andere Werte im Kern abgebildet. 7-53

54 BSD Unix Queues (Einordnung Prio/4): - System-Proz.: 0-49; Benutzer-Proz.: jeweils mit einer Zeitscheibe von 100ms. Anpassen von Prioritäten: - p_cpu = geschätzte CPU-Nutzung eines Proz. (wird für lfd. Proz. alle 10ms inkrementiert). - p_nice = Gewichtungsfaktor vom Benutzer definiert (-20 bis +20). - P USER = statische Priorität des Proz. - nach 4 Ticks (40ms) Update für lfd. Proz.: p_usr = P USER + [p_cpu / 4] + 2*p_nice - Damit Prioritäten nicht ständig wachsen, für alle bereite Proz. jede Sekunde folgende Anpassung: p_cpu = (2*load)/(2*load+1) * p_cpu + p_nice load = Abschätzung d. CPU-Auslastung. Durchschnitt der Summe der Zeitquanten aller Prozesse in der Bereit-Queue der letzten Minute. Probl.: Anpassung nur für rechenbereite Proz. 7-54

55 Dynamische Prioritäten für wartende Proz.: - Neuberechnung d. Priorität wartender Prozesse. - Basis: p_slptime = Wartezeit des Proz. in Sek. - Beim Aufwecken des Prozesses: p_cpu = ( (2*load)/(2*load+1) ) p_slptime * p_cpu Linux Proz. & Threads werden als Tasks verwaltet. Kernel ist nicht verdrängbar. Multilevel Scheduling mit drei Klassen: - SCHED_FIFO: FiFio-Strategie. - SCHED_RR: Zeitscheiben-Verfahren. - SCHED_OTHER: Multilevel-Feedback. Alle aktuell lauffähigen Prozesse werden in einer einzigen Bereit-Queue gespeichert. SCHED_FIFO: 7-55

56 - für Echtzeitprozesse. - Queue nur für root zugänglich. - statische Prioritäten von 1 bis verwendet FCFS innerhalb einer Prio.stufe. - Verdrängung durch Proz. mit höherer statischer Priorität (sonst unlimitierte CPU-Zeit). SCHED_RR: wie SCHED_FIFO, aber Round Robin für jede Prioritätsstufe. SCHED_OTHER: - für normale Prozesse. - statische Priorität: -20 bis + 20 (zu Beginn 0). - Gewichtung mit nice & setpriority (-19 bis +20). - zusätzlich dynamische Anpassung v. Prioritäten. Epochen und Prioritäten: Linux verwendet keine fortlaufende Zeit, sondern Epochen. - In einer Epoche hat jeder Prozess ein best. Zeitquantum für die CPU-Nutzung zur Verfügung. - Dieses wird zu Beginn der Epoche berechnet. 7-56

57 - Proz. kann CPU pro Epoche mehrfach erhalten, sofern sein Zeitquantum nicht verbraucht ist. - Eine Epoche endet, wenn alle Prozesse in der Bereit-Queue ihr Zeitquantum verbraucht haben. - Blockierte Proz. werden hierbei nicht beachtet! Zeitquantum entspricht Priorität. Berechnung des Zeitquantums (ZQ): - Wenn Prozess in Bereit-Queue eingefügt wird - und zu Beginn einer neuen Epoche. - Basis sind 200ms (20 clocks ticks). - falls Zeitquantum (ZQ): o verbraucht: Basis zuteilen. o nicht verbraucht: Basis + ZQ alt /2. - I/O-lastige Proz. verbrauchen ihre Zeitscheibe nicht und erhalten dafür einen Bonus. Prioritäten im Prozesskontrollblock: - rt_priority: statische Prio. von Echtzeitproz. - priority: Basis-Zeitquantum (inkl. nice-gew.). - counter: Anzahl verbleibender CPU-Ticks im Zeitquantum in der akt. Epoche. 7-57

58 Prozessbewertung: Scheduler selektiert Proz. aus Bereit-Queue mit Hilfe der goodness-fkt. Rückgabewert: - -1: Proz. hat CPU freiwillig abgegeben. - 0: Proz. hat Quantum voll ausgenutzt : normaler Proz. mit noch (teilweise) unverbrauchtem Quantum. - >=1000: Echtzeitprozess. Je größer der Rückgabewert, desto besser ist die Bewertung. Berechnung bei normalen Prozessen: if (p->policy!= SCHED_OTHER) return p->rt_priority; // Echtzeitpriorität if (p->counter == 0) // Quantum verbraucht? return 0; if (p->mm == prev->mm) // gleicher Adr.raum? return p->counter + p->priority + 1; 7-58

59 return p->counter + p->priority; 7-59

60 Scheduling in Windows NT Scheduler betrachtet ausschließlich Threads. Verdrängendes, auf Zeitscheiben basierendes Scheduling mit Prioritäten: - Workstation-Zeitscheibe: ms. - Server-Zeitscheibe: ms. 32 Prioritätsklassen (32 FiFo-Queues): - Leerlaufthread: 0. - variable Priorität: Echtzeitpriorität (statisch). 7-60

61 höchste (31) geringste (16) höchste (15) Echtzeitpriorität geringste (0) variable Priorität 7-61

62 Präemptiver Kern, wobei User-Threads auch Kernel-Threads verdrängen können. Prioritäten: - berechnen sich aus der Prozessklasse und dem relativen Thread-Prioritätslevel. - Prozessklassen (PKL): o IDLE: Priorität 4 o NORMAL: Priorität 8 o HIGH: Priorität 13 o REALTIME: Priorität 24 - Thread-Prioritätslevel: o IDLE: Priorität 1 bzw. 16 o LOWEST: Priorität = PKL 2 o BELOW_NORMAL: Priorität = PKL 1 o NORMAL: Priorität = PKL o ABOVE_NORMAL: Priorität = PKL + 1 o HIGHEST: Priorität = PKL + 2 o TIME_CRITICAL: Priorität 15 bzw. 31 Richtige Echtzeitfähigkeiten (Deadlines) nicht vorhanden, sondern nur höhere Prioritäten. 7-62

63 Prioritätserhöhung für GUI-Threads: - Die mit einem Fenster arbeiten u. auf Benutzereingaben oder Fensternachrichten warten. - Auf Priorität 14 & Verdopplung der Zeitscheibe. Prioritätserhöhung nach Blockierung: - Wenn E/A-Auftrag beendet ist, auf den ein Thread gewartet hat, so wird dessen Priorität erhöht (1-8 Level) = Priority Boost. - Nach einem Priority-Boost, wird nach jedem Ablauf einer Zeitscheibe, die Priorität wieder um 1 erniedrigt, bis zum Ausgangswert. Verhungern / Prioritätsinversion: - Rechenbereite Threads, die seit mind. 3 Sek. auf den Prozessor warten. - Priorität auf 15 und Quantum verdoppeln. - Sobald CPU abgegeben bzw. entzogen wird, Werte wieder zurücksetzen. Prioritätsklasse über Taskmgr. anpassbar. 7-63

64 7-64