Prozesse und Threads. Prozesse und Threads Tanenbaum Kap. 2.1, 2.2 Stallings Kap , , 4.5 Glatz Kap

Prozesse und Threads Prozesse und Threads Tanenbaum Kap. 2.1, 2.2 Stallings Kap. 3.1-3.7, 4.1-4.3, 4.5 Glatz Kap. 3.1-3.3 1 1

Inhalt Prozesse Was ist ein Prozess? Prozessausführung Prozessverwaltung Prozesserzeugung Wie wird das Betriebssystem ausgeführt? Threads Was ist ein Thread? Wieso Threads? Threadausführung und Thread-Typen Threads: Schutz und Synchronisation Case Study: Solaris Thread Konzept 2 2

Lehrziele Prozesse Sie können den Begriff Prozess erklären erklären, wie Prozesse auf einer CPU ausgeführt werden die Beschreibung der Prozessausführung erklären und skizzieren den Prozesswechsel und die Ausführungsmodi erklären erklären, wie Prozesse durch das BS verwaltet werden die Prozesserzeugung am Beispiel Unix/Linux erklären und anwenden (Praktikum) erklären und diskutieren, wie das Betriebssystem ausgeführt wird 3 3

Was ist ein Prozess? Prozess Programm in Ausführung nicht zwingend aktiv eigener Kontext - alle Informationen, die den Ausführungszustand beschreiben - Daten, Code, Stack, PSW, Zustandsinfo aller Ressourcen, etc. Kapselung des Programms Sandbox-Konzept Daten PID, Dateiinfo, Zugriffsrechte, Programmcode Stack Prozess CPU Register MMU Register Kernel Stack Kontext 4 Um was gehts? - Jedes Programm (siehe CT1 ) benötigt 3 Speicherbereiche Daten-Bereich (initialisierte und nicht intialisierte Daten) Code-Bereich Stack-Bereich - Annahme: zwei vollständig unabhängige Programme sollen gleichzeitig auf einer CPu laufen. - Frage: Was muss beim Wechseln (Ausfühung) zwischen den Programmen ausgetauscht resp. gespeichert werden? a) die Registerinhalte b) Informationen zum Zustand etc. des Prozesses c) die drei Speicherbereich müssen ausgetauscht werden Punkte a) und b) bilden den Kontext des Prozesses Der Prozess - zu einem Prozess gehören alle Daten, die benötigt werden, damit ein Programm auf einem Rechner ausgeführt werden kann zu einem beliebigen Zeitpunkt unterbrochen werden kann wieder dort gestartet werden kann, wo es unterbrochen wurde - d.h. sämtliche Zustandsinformation muss abgespeichert resp. wiederhergestellt werden 4

Prozess-Kontext Schnappschuss seiner Laufzeitumgebung P 1 aktiv blocked swapped P 2 P n virtual memory System Call Interface CPU I/O main memory computer resources t = T 0 5 Drei Prozessen - Prozess P1: besitzt CPU (läuft resp. ist aktiv) und hat Hauptspeicher alloziert - Prozess P2: ist nicht aktiv, besitzt Disk, hat Hauptspeicher alloziert und wartet auf I/O - Prozess P3: wartet bis Hauptspeicher frei wird - gestrichelte Pfeile: Prozess wartet auf Ressource Informationen zu Prozessen - wie organisiert das Betriebssystem die Informationen zu den einzelnen Prozessen? 5

... was ist ein Prozess? Zweite Sichtweise: Unit of Resource Ownership eine Einheit, die Ressourcen besitzt ein virtueller Adressraum, in dem das Prozess Image steht Kontrolle über Ressourcen (Files, I/O Geräte, etc.) hat Unit of Scheduling eine Einheit, die schedulierbar ist CPU-Scheduler weist der CPU einen Prozess zu (dispatch) zum Prozess gehören der Execution State (PC, SP, Register) und eine Ausführungspriorität 6 6

Prozesse: Hauptaufgaben des BS? Scheduling: Zuweisung an CPU mehrere Prozesse "verschränkt" (concurrent) ausführen - Maximierung CPU-Nutzung - Antwortzeit garantieren Prozessausführung Zustands- und Warteschlangen-Diagramme Ausführungsmodi Mechanismen für Prozesserzeugung und -Terminierung Synchronisation Interprozesskommunikation Ressourcen zur Verfügung stellen jedoch Deadlocks vermeiden 7 7

Prozessausführung auf einer CPU Konzeptmodell 4 Prozesse in Ausführung Prozess-Interleaving auf einer CPU Process a Process b Process c Process d concurrent excution 8 Prozesse werden gleichzeitig bzw. concurrent ausgefürht: ihre Ausführung wird auf einer CPU verschränkt - Prozesse können in der Ausführung unterbrochen und später weiterverarbeitet werden - Prozesse erhalten i.a. die CPU für vorgegebenes Zeitintervall, ausser, der Prozess gibt Kontrolle an CPU zurück (warten auf I/O, etc.) abhängig von Schedulingverfahren Dispatcher bzw. Scheduler bzw. "short time scheduler" - Betriebssystemprogramm, das zwischen Prozessen bzw. Tasks wechselt - Dispatcher: teilt CPU zu - Scheduler: plant die CPU Zuteilung aufgrund eines Algorithmus - verhindert dass nur ein einziger Prozess den Prozessor für sich in Anspruch nimmt - entscheidet wer als nächstes an der Reihe ist ( Scheduling Algorithmus) - Schaltet zwischen Prozessen um Concurrent Computing - jedes Programm macht "Vortschritte" Parallel Computing - Programme arbeiten parllel bzw. echt gleichzeitig 8

Beschreibung Prozessausführung 2 Modelle für Beschreibung Zustandsdiagramme dispatch enter nott running running enter pause Warteschlangen-Diagramme (Queuing-Diagrams) enter Queue dispatch CPU exit pause 9 Prozessausführung - Für die Beschreibung des Ausführens von Prozessen werden zwei Modelle benötigt - Zustandsmodell beschreibt den aktuellen Zustand eines Prozesses, z.b. Running oder Not Running - Queuing-Diagram beschreibt den Ort, wo sich Prozesse aufhalten, wenn Sie sich in einem bestimmten Zustand befinden mehrere Prozesse können sich im gleichen Zustand befinden, z.b. Not Running, in diesem Fall warten sie in einer "Warteschlange" 9

... Beschreibung Prozessausführung Real: Zustandsdiagramm mit 7-Zuständen new admit admit ready suspend ready dispatch timeout running release exit Event occurs blocked suspend activate suspend blocked Event occurs Event wait 10 Zustände - new (neu) der Prozess ist erzeugt, aber noch nicht gestartet - ready (bereit) der Prozess kann ausgeführt werden - running (läuft) der Prozess läuft (ist aktiv) - blocked (blockiert) der Prozess wartet auf Ereignis, z.b. I/O Operation, etc. - suspend blocked (ausgelagert, blockiert) der Prozess wurde ausgelagert und wartet auf Ereignis - suspend ready (ausgelagert, bereit) der Prozess ist ausgelagert, aber bereit für Aktivierung Wenn zu viele Prozesse im Speicher, sinkt Leistungsfähigkeit des System (siehe virtual memory) - Prozesse müssen vollständig auf Disk ausgelagert werden - Zustände blocked suspend und ready ruspend 10

... Beschreibung Prozessausführung Realität: mehrere Queues Prozesse warten in verschiedenen Queues auf Events enter Ready/Run Queue dispatch CPU exit timeout (preemted) Event 1 occurs Event 2 occurs Event n occurs Event 1 Queue Event 2 Queue. Event n Queue Event 1 wait Event 2 wait Event n wait 11 Hinweis - Ready Queue wird oft auch mit Run Queue bezeichnet Für jede Ressource, die blockieren kann, gibt es eine Queue - Disk - Netzwerk - I/O Ports - USB - etc. Ereignis tritt ein, wenn - Daten verfügbar - Daten gesendet - -etc. 11

Wann Prozesswechsel? Wechsel wenn BS Kontrolle über CPU erhält System Call - expliziter Aufruf aus Benutzerprogramm - Prozess wird ev. blockiert, muss aber nicht Interrupt - äussere Ursache: z.b. Timer, DMA beendet, etc. - Kontrolle an Interrupt Handler, oft nur für sehr kurze Zeit Trap - die letzte Instruktion hat einen Fehler erzeugt - Prozess wird ev. Umständen abgebrochen, z.b. Division x / 0 Zwei Möglichkeiten Mode Switch: keine Prozesswechsel, nur "Unterbruch" Context Switch: Prozesswechsel, impliziert auch Mode Switch 12 Gründe für Prozesswechsel - Timer (clock) Zeitintervall abgelaufen Prozess geht in Zustand ready - I/O-Interrupt auf Interrupt wartenden Prozess in den Zustand READY oder READY SUSPEND versetzen entscheiden, ob laufender Prozess unterbrochen oder weiterverarbeitet werden soll Prozess mit höherer Priorität aktiviert werden soll - page fault (virtual memory) adressierter Datenwert steht nicht im physikalischen Speicher, entsprechender Speicherblock muss vom Disk geladen werden Prozess wird in den Zustand blocked versetzt - trap oder exception laufenden Prozess abbrechen - system call die meisten System Calls blockieren den aufrufenden Prozess 12

Prozessausführungs-Modi Prozessausführung in zwei Modi: User Mode: System Mode: mehr privilegiert weniger privilegiert Anwenderprogramme Betriebssystemfunktionen Die meisten modernen Prozessoren unterstützen diese beiden Modi (Hardwareunterstützung) Wieso diese Aufteilung? kritische Systemkomponenten aus Sicherheitsgründen vor unbeabsichtigten resp. unerlaubten Zugriff schützen z.b. PCB, Memory Allocation Tables, IO, etc. 13 System Mode bzw. Kernel Mode Typische Kernel Funktionen - Process Management process creation/termination, scheduling, dispatching, switching, synchronisation, ipc, PCB - Memory Management memory allocation, swapping, page/seg. mgmt - I/O Management buffer mgmt, Allozierung von I/O Kanälen und Geräten an Prozesse - Support Funktionen Interrupt Handling, Accounting, Monitoring 13

Ausführung: Mode Switch Prozess P 0 State Stack idle Interrupt Service Routine System Mode State Stack 14 State: Prozesszustand (Register, PSW) Mode Switch - nur der Prozessor-Zustand muss bzw. wird auf Stack gespeichert, d.h. die Prozessor Register und die Flags - wenig Overhead der Prozesskontrollblock muss nicht aufdatiert werden, wie bei Prozesswechsel - SW oder HW-Interrupt machen vorerst keinen Context Switch notwendig ISR wird im gleichen Prozesskontext, aber im System-Mode ausgeführt - Kontrolle über CPU Rückkehr in das unterbrochene Programm falls Prozess blockiert (abhängig vom System Call) Context Switch 14

Ausführung: Context Switch Prozess P 0 Prozess P 1 State PCB 0 idle PCB 1 State idle PCB 1 State State PCB 0 idle 15 State: Prozesszustand (Register, PSW) Context Switch (Prozesswechsel) - gesamter Prozesszustand muss abgespeichert werden Prozessorzustand und sämtliche Register (auch MMU, etc.) speichern - Prozesskontrolblock aufdatieren - Prozesskontrollblock an die entsprechende Liste hängen - neuen Prozess für Ausführung auswählen - Prozesskontrolblock aufdatieren - Prozessorzustand und Register wiederherstellen kostspielige Operation - Time Sharing Systeme: ca. 10 bis 1000 Context Switches/s. 15

Prozesswechsel durch Scheduler/Dispatcher Scheduler resp. Dispatcher Context Switch notwendig - Grund: blockierender System Call oder Time Slice abgelaufen - Scheduler wählt Prozess aus Ready Queue - mögliche Auswahlkriterien minimale Antwortzeit maximaler Durchsatz faire CPU Zuteilung (CPU) Auslastung CPUs kein Context Switch notwendig - Rückkehr in unterbrochenen Prozess Scheduling Verfahren später 16 16

Prozess- und Ressourcenmangement Betriebssystem Tabellen Verwaltung von Prozessen und Ressourcen 17 Wie organisiert das Betriebssystem Informationen zu den einzelnen Prozessen? - das BS unterhält und verwaltet verschiedenste Tabellen für die Verwaltung von Prozessen und Ressourcen: Speicher Memory Tabellen Geräte Files CPU I/O Tabellen File Tabellen Prozess Tabellen - Information in verschiedenen Tabellen gespeichert - konzeptuell werden obige Tabellen von jedem Betriebssystem benötigt, die Implementierung ist jedoch überall verschieden Anmerkung - die Tabellen müssen selbst wieder miteinander verknüpft sein, d.h. ein Prozess muss wissen welche Files er benutzt, etc. 17

Prozess Image im Virtual Memory Process Identification Process State Information Process Control Information Process Identification Process State Information Process Control Information Process Identification Process State Information Process Control Information Process Control Block Program / Text Program / Text Program / Text Data Data Data Heap Heap Heap Program Layout User Stack User Stack User Stack Shared Address Space Shared Address Space Shared Address Space Process 1 Process 2 Process 3 18 Prozess Image besteht aus - Benutzerprogramm (Code bzw. Text), Daten, Stack, Heap - Kontext, im Prozesskontrollblock (PCB) gespeichert PCB, eine Datenstruktur mit Zustandsinformation zum Prozess Process Images sind im virtuellen Speicher abgelegt (ab Adresse 0) - virtueller Speicher wird mit Hilfe der Memory Management Unit auf den physikalischen Speicher abgebildet nicht notwendigerweise ein kontinuierlicher Speicherbereich - privater und gemeinsam genutzter Adressraum - Teile des Prozesses können auch auf dem Sekundärspeicher abgelegt sein Primärprozesstabelle hat Einträge (Zeiger) auf die entsprechenden Prozess Images - abhängig von der Speicherorganisation Das BS hat nur Zugriff auf Prozessdaten, wenn das Prozessimage teilweise im physikalischen Speicher steht Linux-Prozessimage Map (Layout) anzeigen mit - pmap PID - cat /proc/pid/status 18

Der Prozesskontrollblock PCB PCB: eine der wichtigsten Datenstrukturen im BS speichert Prozesskontext ist Teil des Prozessimages Zustand des Betriebssystems "the set of the process control blocks defines the state of the operating system" Enthält alle notwendige Information zum Prozess Process Identification Process Control Information Processor State Information Zugriff auf PCB hochkritisch nur über entsprechende Handler-Routine 19 Process Identification - eindeutiger Prozessidentifikator: immer vorhanden zeigt in die primäre Prozesstabelle PID: Process Identifier - Prozessidentifikator des Elternprozesses Erzeuger des aktuellen Prozesses - Benutzeridentifikation wer ist für diesen Prozess verantwortlich UID: User Identifier, ev. GID: Group Identifier Process State Information - Inhalt der Prozessorregister für den Benutzer sichtbare Register (Daten, Adressen) Kontroll- und Statusregister Stackpointer, Programmzähler Prozessor Status Wort (PSW), Flags Process Control Information - Scheduling und Zustandsinformation - Informationen zu Queues, Prozessprivilegien, Memory Management Ressourcen: Besitzer und Benutzung 19

Queues: Linked List von PCBs Queues Prozesskontrollblöcke Running head tail PCB A Null Ready head tail PCB B PCB B Null Blocked head tail Null Null 20 20

Prozesserzeugung Eindeutigen Prozessidentifikator erzeugen Speicher für Prozess Image allozieren Prozesskontrollblock initialisieren Defaultwerte setzen, z.b. - Zustand: NEW, I/O Geräte, offene Files - etc. Verkettungen für Queues aufsetzen z.b. Prozess in die Liste mit neuen Prozessen einfügen Weitere Datenstrukturen initialisieren z.b. Accounting Informationen Prozesse oft hierarchisch organisiert Eltern- und Kindprozesse 21 21

Prozesserzeugung unter Unix/Linux Prozesserzeugung System Call fork() erzeugt Kindprozess System call exec() startet neues Programm fork() erstellt "Kopie" des Elternprozesses Prozesserzeugung bei Systemstart Prozess 0 (Prozess init) - zur Bootzeit erzeugt - spaltet Prozess 1 ab - wird selbst zum Swapper Prozess 1 - startet Deamonprozesse - erzeugt neuen Prozess, wenn sich ein Benutzer anmeldet - Vater aller Prozesse, sorgt auch für "Waisenkinder" 22 Alle Prozesse unter Unix haben einen Elternprozess - Ausnahme Prozess 0, der nicht nicht mehr in der Prozessliste erscheint Bezeichnungen - der Erzeuger wird parent genannt (Elternprozess, Vaterprozess, Erzeugerprozess, etc.) - der neue Prozess heisst child (Kindprozess, Kind) - das Kind ist eine "fast identische Kopie des Vaters (gleicher Code, Daten, offene Files, etc.), aber eigene PID siehe Praktikum Funktionalität / Arbeitsweise - der Elternprozess kann gleichzeitig mit dem resp. den Kindern arbeiten - der Elternprozess kann entweder auf die Beendigung eines oder mehrerer Kinder warten - Kinder, die terminieren und auf die der Elternprozess nicht wartet, werden zu Zombies - Zombies belegen Betriebssystem-Ressourcen müssen verwaltet werden: in diesem Zustand können z.b. Accounting Informationen abgefragt werden - Zombies können verhindert werden siehe Praktikum 22

Prozesserzeugung unter Unix/Linux main() Beispiel: Prozesserzeugung unter Unix / Linux ret=fork(); ret==pid c ret==0 #include <sys/types.h> #include <stdio.h> execl(...); int main(void) { pid_t ret; ret = fork(); // make child if (ret == 0) { // child: return value = 0 printf("i am the child\n"); if (execl(./test,null)<0) { // start program "test" printf( could not exec ); // should not come here exit(-1); } } else // parent: return value = PID c wait(null); // wait for child to terminate } 23 23

Prozesserzeugung unter Unix exec(...) überlagert Programm- und Datenbereich mit neuem Programm und neuem Datenbereich Prozesskontext wird von Eltern geerbt - ermöglicht Zugriff auf offene Files des Elternprozesses - etc. COW: Copy On Write (viele Unix Implementationen) fork() - Kindprozess nicht vollständige Kopie des Elternprozesses - Datenbereiche nur erzeugt, wenn Kind Daten schreibt - schneller, wenn anschliessendes exec() den Programmund Datenbereich neu erzeugt 24 Viele Unix Implementationen erstellen bei fork() zuerst keine Kopie von den Speicherbereichen - Kindprozess wird oft mit exec() überlagert - wäre deshalb ineffizient Diese Systeme verwenden das COW-Verfahren: Copy On Write - es wird keine Kopie erstellt wenn nur gelesen wird alle nur lesbaren Bereiche können problemlos gemeinsam genutzt werden - es wird eine Kopie erstellt wenn geschrieben wird schreibbare Bereich werden erst erzeugt resp. kopiert, wenn der Prozess versucht in diesen Bereich zu schreiben 24

Wie wird das BS ausgeführt? Das BS arbeitet wie normale Computersoftware wird als Programm vom Prozessor ausgeführt Das BS gibt oft Kontrolle ab Prozessor muss aber Kontrolle wieder an BS zurückgeben Was ist das Betriebsystem ein Programm? ein Prozess? eine Menge von Programmen und Prozessen? hängt von Implementation ab 25 25

Kernel mit eigenem Kontext (ältere BS) P 1 P 2 P n Kernel Kernel mit eigenen Kontext nur Benutzerprogramme sind Prozesse Betriebssystemcode - eigenständiges Programm mit eigenem Kontext - wird im System Mode ausgeführt innerhalb eines Benutzer-Prozesskontextes wird nie Betriebssystemcode ausgeführt 26 Der Kernel kann als eigenständiges Programm betrachtet werden, konzeptuell werden nur Anwenderprogramme als Prozesse betrachtet BS resp. Kernel hat eigenen Daten- und eigenen Stackbereich, also einen eigenen Kontext 26

BS-Funktionen im Kontext der Benutzerprozesse P 1 P 2 P n BS-Funktionen Funktionen zum Prozesswechsel BS-Funktionen im Kontext der Benutzerprozesse BS stellt "nur Funktionen" zur Verfügung - Betriebssystemcode im Kontext des Benutzerprozesses System Calls, Interrupts, Traps - CPU schaltet in System Mode, Ausführung aber im Benutzerkontext Context Switching meist ausserhalb von Prozessen 27 Wird eher von kleineren BS verwendet: PC, Workstation Konzeptuelle Sicht - BS ist Sammlung von Prozeduren, die vom Anwender aufgerufen werden BS Code, Bibliotheken und z.t. Daten in Shared Region des Benutzerprozesses abgebildet z.b. von UNIX/Linux verwendet 27

Prozessbasiertes Betriebssystem U 1 U 2 U n OS 1 OS 2 OS n Funktionen für Prozesswechsel und IPC Prozessbasierte Betriebssysteme kleine Anzahl von Systemfunktionen (Prozesswechsel, IPC) ausserhalb von Prozessen Microkernel das BS ist eine Sammlung von Systemprozessen grössere Kernel Funktionen sind eigenständige Prozesse gut geeignet für Multiprozessorsysteme 28 Vorteile - fördert modulare BS Implementation mit sauberen Schnittstellen - nicht kritische Funktionen problemlos als Prozesse implementierbar - implementieren z.b. Funktionen, die nicht einen speziellen Service anbieten, sondern allgemeiner sind: accounting - gut geeignet für Multiprozessorsysteme - schlanker Kernel - leicht erweiterbar Nachteil - relativ hohe Interprozesskommunikationskosten 28

Prozesse und Threads Threads Tanenbaum Kap. 2.2 Stallings Kap. 4 Glatz Kap. 3 29 29

Lehrziele Threads Sie können den Unterschied zwischen Thread und Prozess erklären und diskutieren, sowie Anwendungen und Vorteile aufzeigen die Threadausführung erklären und diskutieren Threadtypen aufzählen und diskutieren das Solaris Prozess- und Threadkonzept erklären können 30 30

Threads Leightweight Prozesse Thread-Konzept starke Zunahme der Bedeutung wegen Multicore-Prozessoren unterstützt Software- und Hardware-Parallelität relativ einfache Handhabung Threads unterstützt durch Bibliotheken (Lösung auf Betriebssystemebene) - z.b. PThread Library (POSIX Standard) Programmiersprachen - Java, C#, Python, etc. - neu C++11 (C11) - OpenMP: Direktiven (C, C++, Fortran) für Multithreading - eigene Implementation oder Abbildung auf PThreads 31 31

slide Thread vs. Prozess Prozess: verwaltbare Einheit Prozess: unit of resource ownership Prozess: unit of scheduling Moderne Betriebssysteme trennen Eigenschaften Prozess: unit of resource ownership Thread: unit of scheduling Multithreading mehrere Threads pro Prozess Vorteile Threadwechsel weniger aufwendig bzw. billiger Aufgabenteilung unterstützt Multicore-Prozessoren 32 Prozess: "heavyweight process" - virtueller Adressraum, Programmcode, Daten, Betriebssystem-Ressourcen - single thread of exection Thread: "lightweight process" - immer an Prozess gebunden - unabhängiges Stück Code innerhalb eines Prozesses - teilt sich mit anderen Threads Adressraum, Daten, Kontext - hat eigene lokale Variablen, Register, PC, Stack, Stackpointer - hat Ausführungszustädend running, ready, etc. - speichert Threadkontext wenn inaktiv 32

Thread vs. Prozess Ressourcen und Scheduling Prozess Ressourcen Scheduling gemeinsame globale Daten Stack Stack PC PC offenes File output.txt Zugriff auf Drucker Thread A Thread B 33 33

Single- vs. Multithreading DOS ein Prozess ein Thread ecos (RedHat) ein Prozess mehrere Threads UNIX Solaris / Linux...... mehrere Prozesse ein Thread pro Prozess mehrere Prozesse mehrere Threads pro Prozess 34 Single Threading - das Betriebssystem kennt das Konzept des Threads nicht Multithreading - das Betriebssystem unterstützt die gleichzeitige Ausführung mehrerer Threads innerhalb eines Prozesses Beispiele - DOS unterstützt einen Benutzerprozess und einen Thread - UNIX unterstützt mehrere Prozesse, aber nur einen Thread pro Prozess - Solaris unterstützt mehrere Threads und mehrere Prozesse - ecos mehrere Threads, ein Prozess: Echtzeitbetriebssystem, von RedHat vertrieben 34

PThreads (POSIX): ein Beispiel #include <pthread.h> int avar = 16; // global avar void *PrintMessageFunction(void* ptr) { // print specified message printf("%s: %d\n", (char*)ptr, avar++); //!!!!! } int main (void) { pthread_t char char thread1, thread2; *message1 = "Hello"; *message2 = "World"; rv = pthread_create(&thread1, NULL, PrintMessageFunction, (void*)message1); assert(rv == 0); rv = pthread_create(&thread2, NULL, PrintMessageFunction, (void*)message2); assert(rv == 0); //...Bemerkung: 2. Param NULL entspricht "pthread_attr_default" pthread_join (thread1, NULL); pthread_join (thread2, NULL); // wait for termination of // specified threads } printf("hauptprogramm (Vater-Thread) beendet \n"); exit(0); 35 POSIX - Portable Operating System Interface Achtung - das Programm läuft nicht korrekt - "avar++" race condition 35

Wieso Threads? Thread ist "billig" Thread kann schnell erzeugt und beendet werden braucht nur Stack und Speicher für die Register Threadwechsel schnell nur PC, SP und Register austauschen Threads benötigen wenig Ressourcen keinen neuen Adressraum, keinen eigenen Datenbereich oder Programmcode keine zusätzlichen Betriebssystemressourcen Aber kein "Schutz" zwischen Threads 36 Anwendungen - Daten Server mehrere Anfragen "gleichzeitig" innerhalb kurzer Zeit bearbeiten pro Anfrage ein Thread ist effizienter als ein Prozess - Spreadsheet ein Thread behandelt Anzeige und Input ein Thread führt Befehle aus (im Hintergrund) - Parallelverarbeitung mit viel Kommunikation Zugriff auf gemeinsame Datenbereiche ist effizienter Matrixmultiplikation auf mehrere Threads verfteilen - Programme mit Vorder- und Hintergrundaktivitäten z.b. in regelmässigen Abständen Daten sichern Texteditor: Texteingabe - Korrektur - Datensicherung - Repetitive numerische Aufgaben in unabhängige Teilaufgaben aufteilen, ein Thread pro Teilaufgabe (z.b. Wetterberechnungen) Ungeeignete Anwendungen - wenn kein Multiprozessing notwendig ist - wenn mehrere Prozesse notwendig sind, z.b. Sicherheit, etc. 36

... wieso Threads? Z.B. Serveranfrage auf Uniprozessor Prozess 1 Server 1 Server 2 t Server 1 Thread A (Process 1) Thread B (Process 1) Server 2 37 Anfrage eines Programmes an zwei Server - ohne Threading Verarbeitung durch zwei unabhängige Threads: Anfragen sequentiell die "Summe" der beiden Anfragen bestimmt die Verzögerung - mit Threading beide Anfragen fast gleichzeitig die längere Anfrage bestimmt die "Verzögerung" (falls beide Antworten für Weiterverarbeitung benötigt wird) 37

... wieso Threads? Z.B. Arbeitsteilung mit SMP Single Thread CPU t Multiple Threads CPU 1 CPU 2 CPU 3 CPU 4 38 Anfrage eines Programmes an zwei Server - ohne Threading Verarbeitung durch zwei unabhängige Threads: Anfragen sequentiell die "Summe" der beiden Anfragen bestimmt die Verzögerung - mit Threading beide Anfragen fast gleichzeitig die längere Anfrage bestimmt die "Verzögerung" (falls beide Antworten für Weiterverarbeitung benötigt wird) 38

... wieso Threads? Effizienzsteigerung durch Multithreading nur blockierter Thread muss warten - gilt nur für Kernel Threads schneller Threadwechsel bessere CPU-Auslastung - concurrent Ausführung mehrerer Threads Symmetrisches Multiprocessing Multicores Threads schnell erzeugbar, Thread Pool echt parallele Ausführung mehrerer Threads gemeinsame Daten in Shared Memory - einfacher und effizienter Datenzugriff - aber Achtung: Data Races 39 39

Threadausführung Threads: 3 resp. 5 Zustände Running, Ready und Blocked (New und Stopped) new ready running stopped blocked kein Zustand Suspend: alle Threads im gleichen Adressraum Swapping: Prozesses mit allen Threads suspendiert Prozesses terminiert alle Threads terminieren Was geschieht wenn ein Thread blockiert? user level threads der Prozess blockiert kernel level threads der Thread blockiert 40 40

Thread-Typen User-Level Threads(ULT) Kernel weiss nicht, dass es Threads gibt Threads laufen im Benutzerbereich realisiert mit Bibliotheken Thread Library P User Space Kernel Space Kernel-Level Threads(KLT) Kernel weiss, dass es Threads gibt Kernel stellt Systemfunktionen für Threadverwaltung zur Verfügung API zu Threadfunktionen im Kernel KLT: light weight process P User Space Kernel Space 41 41

User Level Threads (ULT) Der Kernelweissnicht, dass es Threadsgibt Anwendung verantwortlich für das Threadmanagement (Bibliotheksfunktionen) Threadwechsel benötigt keine Kernel Mode Privilegien Threadscheduling applikationsspezifisch wählbar Thread Bibliothek - Speichern und Rückspeichern des Threadkontextes - Threads erzeugen und beenden - Scheduling Thread Library User Space Kernel Space P 42 Was macht der Kernel bei User-Level Threads? - Kernel weiss nichts von Threadaktivitäten, kontrolliert aber nach wie vor die Prozessaktivitäten - Thread macht einen System Call ganze Prozess blockiert, auch die anderen Threads dieses Prozesses: die meisten System Calls blockieren - aus Sicht des Threadschedulers ist der Thread nach wie vor am Laufen Thread Zustände sind unabhängig von Prozesszuständen Threads können nicht unterbrochen werden, können nur freiwillig Kontrolle über CPU abgeben Vorteile von User-Level Threads Threadwechsel involviert Kernel nicht Läuft auf jedem Betriebssystem (Bibliothek notwendig) Schedulingverfahren kann anwendungsspezifisch gewählt werden, aber oft nicht preemptive Schnell und einfach Nachteile von User-Level Threads Die meisten System Calls blockieren Prozess blockiert und damit auch die anderen Threads des Prozesses Nur der Kernel kann Prozesse den Prozessoren zuweisen, d.h. Paralleverarbeitung ist nicht möglich Page Fault eines Threads blockiert ganzen Prozess 42

Kernel Level Threads (KLT) Thread Management durch Kernel keine Bibliothek, sondern API zu Threadfunktionen des Kernels Kernel verwaltet Kontextinformation von Prozessen und Threads Threadwechsel erfordert Intervention des Kernels Schedulierbare Einheit: Thread Threads können auf mehrere Prozessoren verteilt werden Beispiele - Solaris, Win/NT, OS/2, Linux User Space Kernel Space P 43 Threadwechsel - zwei Mode Switches Vorteile von Kernel-Level Threads - Kernel kennt alle Threads Prozess mit 10 Threads kann anders behandelt werden als Prozess mit einem Thread - Scheduling auf Thread Basis - geeignet für Anwendungen die häufig blockieren, z.b.server mit viel Interprozesskommunikation - Kernelfunktionen können selbst Multithreaded sein - geeignet für SMP Nachteile von Kernel-Level Threads - Threadwechsel innerhalb eines Prozesses durch Kernel kostet 2 Mode Switches - spürbarer Overhead und höhere Kernelkomplexität jeder Thread benötigt Thread Control Block (TCB) - spürbar langsamer bei 1 CPU 43

Kombination KLT/ULT Kombination Threads im User Space erzeugt Scheduling und Synchronisation hauptsächlich im User Space Programmierer kann zur Optimierung die Anzahl KLTs anpassen - kann beide Verfahren optimal kombinieren Beispiel: Solaris P Thread Library P User Space Kernel Space 44 44

Threads: Schutz und Synchronisation Threads nutzen gemeinsam Ressourcen Inter-Thread Kommunikation ohne Kernel-Hilfe möglich - globale Daten gemeinsam kein Schutz der Daten gegen unbeabsichtigten Zugriff Synchronisation notwendig Synchronisation Koordination der Ausführung von Threads Datenkonsistenz garantieren: keine Race-Conditions - Race-Condition gleichzeitiger Zugriff von 2 Threads davon 1 Schreibzugriff - z.b. "avar++" Race Condition 45 45

Solaris case study: Threads und Prozesse L L L L L L L L Threads Library L User Space Kernel Space Hardawre P P P P P User Level Thread Kernel Level Thread L Leight weight Process P Processor 46 Prozess - normaler Unix Prozess (User Address Space, Stack, PCB) - enthält einen oder mehrere Lightweight Prozesse User Level Thread (Bibliotheksfunktionen) - unsichtbar für das Betriebssystem - Schnittstelle zu Parallelität auf Applikationsebene - bound: fest an LWP angebunden - unbound: wird einem LWP zugewiesen Light-weight Process (LWP) - Bindeglied zwischen ULT und KLT - unterstützt mehrere ULTs, hat Verbindung zu einem KLT Kernel Level Threads - schedulierbare (und dispatchable) Einheiten User Level Threads werden benutzt, wenn logische Parallelität keine Unterstützung von Hardwareparallelität erfordert - Beispiel: Mehrere Fenster auf dem Display (logische Parallelität), aber nur eines ist aktiv (keine Hardwareparallelität) Mehrere LWPs für Anwendungen die blockierende Threads (I/O, etc.) enthalten - Prozess (Anwendung) blockiert nicht, wenn ein Thread blockiert - blockierende Threads einzeln an einen LWP binden - Beispiel: Matrixoperationen auf mehrere Threads abbilden: ein Thread an einen LWP binden kein Threadwechsel notwendig (im User Bereich) - Mischung bound / unboud: bound für Echzeitanwendungen (z.b. hohe Priorität), unbound für Hintergrundtasks Das Konzept erlaubt - 1:1 mapping - 1:n mapping - m:n mapping 46

Solaris: Threads und Prozesse Prozess normaler Unix Prozess (User Address Space, Stack, PCB) enthält einen oder mehrere Lightweight Prozesse User Level Thread (Bibliotheksfunktionen) unsichtbar für das Betriebssystem Schnittstelle zu Parallelität auf Applikationsebene bound: fest an LWP gebunden unbound: wird jeweils einem LWP zugewiesen Lightweight Process(LWP) Bindeglied zwischen ULT und KLT unterstützt mehrere ULTs, hat Verbindung zu einem KLT Kernel Level Threads schedulierbare (und dispatchable) Einheiten 47 Wann User Level Threads? - logische Parallelität benötigt keine Unterstützung durch Hardware-Parallelität - Beispiel: mehrere Fenster auf dem Display logische Parallelität nur eines ist aktiv keine HW-Parallelität Mehrere LWPs? - für Anwendungen mit blockierenden Threads (I/O, etc.) - Prozess (Anwendung) blockiert nicht, wenn ein Thread blockiert - blockierende Threads einzeln an einen LWP binden - Beispiel: Matrixoperationen auf mehrere Threads abbilden einen Thread an einen LWP binden kein Threadwechsel notwendig (im User Bereich) - Mischung bound/unboud: bound für Echzeitanwendungen (z.b. hohe Priorität) unbound für Hintergrund-Tasks 47