Betriebssysteme Grundlagen, Konzepte

Transkript

1 Betriebssysteme Grundlagen, Konzepte Prozessmanagement Version 1.9 Fachhochschule Frankfurt (Main) University of Applied Sciences Seite 1(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

2 Inhaltsverzeichnis 1 PROZESSMANAGEMENT PROZESSE PROZESSHIERARCHIE PROZESSE UNTER UNIX PROZESSZUSTÄNDE PROZESS SWITCH SCHEMATISCHE INTERRUPTBEHANDLUNG PROZESS MODUS PROZESSERZEUGUNG PROZESS-SCHEDULING FIRST COME, FIRST SERVE SCHEDULING SHORTEST JOB FIRST ROUND-ROBIN-SCHEDULING PRIORITÄTENGESTEUERTES SCHEDULING MEHRERE QUANTENWARTESCHLANGEN A-PRIORI-SCHEDULING ZWEISTUFIGER SCHEDULER PROZESS-SCHEDULING UNTER UNIX PROZESSKOMMUNIKATION ZEITKRITISCHE ABLÄUFE LÖSUNGSANSÄTZE LÖSUNGEN KLASSISCHE PROZESSKOMMUNIKATIONSPROBLEME DAS PHILOSOPHENPROBLEM DAS LESER-SCHREIBERPROBLEM DAS FRISEURPROBLEM ZUAMMENFASSUNG PROZESSMANAGEMENT C-PROGRAMME ZUM ERZEUGER-VERBRAUCHER PROBLEM IPC MIT SHARED MEMORY IPC MIT SHARED MEMORY NACH PETERSON PROZESSKOMMUNIKATION IN C-PROGRAMMEN 44 Seite 2(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

3 Dieses Dokument wird von Gerd Neugebauer erstellt. Dokumentstatistik Das Dokument wird zu den Vorlesungen aktualisiert. Änderungen an Inhalt und Umfang führen zu neuen Hauptversionsnummern. Version Datum Autor Inhalt und Änderungsaktionen Gerd Neugebauer Betriebssysteme Vorlesung WS Gerd Neugebauer Betriebssysteme Vorlesung WS Gerd Neugebauer Betriebssysteme Vorlesung Statistische Informationen der Datei-Information Datum des Ausdrucks Anzahl der Seiten 47 Anzahl Zeichen Dokumentname Titel des Dokuments 7. Prozesse.doc Betriebssysteme Semester Autor des Dokuments Seite 3(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

4 1 Prozessmanagement 1.1 Prozesse Prozesse und das dazugehörige Prozessmanagement sind ein Schlüsselkonzept eines jeden Betriebssystems, das wichtigste? Auf jeden Fall unverzichtbar. Ein Prozess ist ein Programm, das sich gerade in Ausführung befindet. Zur Abgrenzung die folgende Definition Ein Programm ist ein statisches Textstück, das eine Folge von Aktionen spezifiziert, die von einem oder mehreren Prozessoren auszuführen sind. Ein Prozess ist eine durch ein Programm spezifizierte Folge von Aktionen deren erste begonnen hat und deren letzte noch nicht abgeschlossen ist. Ein Computer muss heute viele verschiedene Aufgaben auf einmal quasi parallel abwickeln Berechnungen, Terminal I/O, Drucken,....Die Kontrolle vieler paralleler Aktivitäten ist Aufgabe des Prozessmanagements. Aufgaben des Prozessmanagements sind so u.a.: - Starten und Beenden von Prozessen - Suspendieren und Resuspendieren von Prozessen - Bereitstellung von Mechanismen zur Programmsynchronisation - Bereitstellung von Mechanismen zur Programmkommunikation - Deadlock Behandlung Die entscheidende Idee: Ein Prozess stellt eine Aktivität beliebiger Art dar. Er besitzt ein Programm mit einem dazugehörigen Programmzähler, Eingaben, Ausgaben und einen aktuellen Zustand in dem sich der Prozess befindet. All dies wird in einem prozessspezifischen Prozesskontext hinterlegt, in dem ProcessControlBlock, im PCB Prozesshierarchie In der Regel können Prozesse wieder Prozesse erzeugen (fork). So entsteht im System eine Prozesshierarchie: Vaterprozess Kindprozess. Prozesshierarchie: Starten eines UNIX-Systems und Anmelden eines Benutzers init getty login bash ksh Seite 4(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

5 Prozessbeschreibung: Starten eines UNIX-Systems und Anmelden eines Benutzers - UNIX-Systemkern /UNIX wird in den Hauptspeicher geladen und zur Ausführung gebracht. "Kern Prozess" (Kernel) PID 0. - "Kern Prozess" startet das Programm /etc/init. Dieser Prozess hat die PID 1 und ist der eigentliche Urprozess für alle Benutzerprozesse. Außerdem werden in der Regel die Prozesse swapper und der pagedämon gestartet. - /etc/init liest die Datei /etc/inittab in der alle angeschlossenen Terminals verzeichnet sind. Für alle als zu aktivierende gekennzeichneten Terminals startet die /etc/init einen Sohnprozess, der zunächst stdin, stdout, stderr öffnet und anschließend /etc/getty startet. - /etc/getty gibt die Anforderung zum Anmelden am entsprechenden Terminal aus. - Nach der Eingabe der Login - Kennung ruft /etc/getty das Kommando /bin/login auf. Dieses Kommando fragt das Passwort ab und prüft es. Ist das Passwort richtig, so ruft /etc/init die in der Datei /etc/passwd spezifizierte Login - Shell auf. Dieses Programm ist nicht nur der Kern neuer Prozesse, sondern es läuft auch unter der gleichen PID wie die von /etc/init erzeugten Sohnprozesse /bin/sh /bin/csh /bin/ksh - Bevor einem Benutzer die Eingabe eines Kommandos gestattet wird, wird eine für alle Nutzer gleiche Kommandoprozedur /etc/profile gestartet. Falls vorhanden wird die Startup-Datei.profile im Home- Verzeichnis des Anwenders ausgeführt z.b. die /home/neuge/.bashrc. - und ab jetzt darf er eigene Kommandos eingeben Prozessausführung: Wird ein Kindprozess erzeugt gibt es für den Elternprozess die Möglichkeiten: 1. Elternprozess läuft parallel weiter zu den Kindprozessen 2. Elternprozess wartet ( wait() ) bis einer oder alle Kindprozesse terminiert sind Bezüglich des Adressraumes des neuen Prozesses gibt es die Möglichkeiten: 1. Kindprozess ist eine Kopie des Elternprozesses ( fork() ). Der Elterprozess bleibt erhalten. 2. Kindprozess ist ein Programm, das von dem Elternprozess geladen wird ( exec() ). Der neue Prozess überlagert dabei den aufrufenden Prozess. Ein erfolgreicher exec() Aufruf kehrt nicht zurück. Mit einem exec() wird kein neuer Prozess erzeugt, sondern innerhalb eines fortbestehenden Prozesses lediglich ein Programm durch ein anderes überlagert. Prozessstart: Neue Prozesse werden nicht gestartet, wenn - die Maximalzahl von Prozessen erreicht ist - die Maximalzahl von Prozessen eines Benutzers erreicht ist - kein Platz im Hauptspeicher und swap-bereich mehr vorhanden ist Prozessbeendigung: Ein Prozess terminiert, wenn - es die letzte ausführbare Anweisung ausgeführt hat, dann fordert der Prozess das Betriebssystem auf, ihn zu löschen ( exec-aufruf ) - er durch ein Ereignis terminiert wird ( z.b. Interrupt, Systemaufruf ). Prozesse können auch andere Prozesse terminieren, wenn sie die Identität des Prozesses kennen und die Berechtigung dazu haben (Superuser oder Eigentümer). Seite 5(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

6 1.1.2 Prozesse unter UNIX Bei Absetzen eines UNIX-Kommandos wird in aller Regel ein Prozess gestartet. Einige Kommandos sind allerdings direkt in der Shell eingebaut, die builtin-kommandos, für diese Kommandos wird kein eigener Prozess gestartet. Der Prozess wird im Betriebssystem durch einen Eintrag in der Prozesstabelle dargestellt, unter Unix der PCB (Process Control Block). Dieser beschreibt den Zustand des Prozesses und dient zur Speicherung der prozessspezifischen Daten. jeder Prozess ist eindeutig identifizierbar durch seine PID (Process Identification) - Bei der Erzeugung erhält jeder Prozess eine eindeutige Nummer, die er bis zum Ende beibehält. PPID (Parents Process Identification) - Jeder Prozess kennt die PID seines Elternprozesses. Auch wenn ein Prozess nicht aktiv ist, benötigt das System ständig Informationen aus dem Prozess- Kontext, aus der Systemstruktur eines Prozesses, um die Prozesse verwalten zu können. Wenn der Prozess läuft, benötigt er darüber hinaus alle Informationen, die zum User gehören, die in der User-Struktur enthalten sind. Die User-Struktur des aktuellen Prozesses muss im Arbeitsspeicher liegen. Bei einem Kontextwechsel werden die Informationen aus den prozessspezifischen Strukturen des alten Prozesses mit der des neuen Prozesses ausgetauscht. Einige Felder eines PCBs eines Prozesses in der Prozesstabelle: Prozessverwaltung Speicherverwaltung Dateiverwaltung Register Zeiger auf Textsegment umask-maske Programmzähler Zeiger auf Datensegment Wurzelverzeichnis Programmstatuswort Zeiger auf BS-Segment aktuelles Verzeichnis Stack-Zeiger Terminierungsstatus Dateideskriptor Prozesszustand Prozessnummer effektive UID Prozesserzeugungszeitpunkt Elternprozess effektive GID verbrauchte Prozessorzeit Prozessgruppe Systemaufrufparameter Prozesszustände Ein Prozess kann Ausgaben erzeugen. Diese Ausgaben können Eingabe für einen nächsten Prozess sein. (Pipemechanismus). Wartet ein Prozess auf eine Eingabe, so ist er blockiert und kann nicht weiter arbeiten, bis die Eingabe wieder zur Verfügung steht. Diese Warten ist im Problem begründet. Eine andere Art von Suspendierung eines Prozesses kann dann eintreten, wenn das Betriebssystem dem Prozess den zugeteilten Prozessor entzieht, weil die Zeitscheibe für aktuellen Prozess abgelaufen ist. Es gibt i.r. mehr Prozesse als Prozessoren. Die zeitliche Reihenfolge, wann einem Prozess ein Prozessor zugeteilt wird, wird mit Hilfe eines Scheduling Algorithmus (Scheduler) berechnet. Es gibt im Prinzip die folgenden 3 Prozesszustände: 1. laufend oder auch rechnend (running): Prozess benutzt CPU 2. blockiert oder auch schlafend (sleeping): wartet auf externes Ereignis (z.b. warten auf Eingaben) 3. (rechen)bereit (ready): lauffähig; vom Betriebssystem gestoppt, während ein anderer Prozess läuft Seite 6(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

7 (1) Prozess blockiert (z.b..: wartet er auf Eingabe) (2) Zeitscheibe ist abgelaufen: Scheduler wählt einen anderen Prozess (3) Der Prozess wurde von Scheduler als nächster ausgewählt. (4) Externes Ereignis tritt ein: der Prozess ist wieder bereit Die gesamte Unterbrechungsbehandlung, das Erzeugen und Abbrechen von Prozessen wird durch den Prozess-Scheduler verborgen. Daneben gibt es noch weitere Prozesszustände, die Übergangszustände sind, oder Fehlercharakter haben: 4. dead: Der Prozess wurde beendet, er belegt jedoch noch Speicherplatz. 5. trace: Der Prozess wurde von außen angehalten, üblicherweise durch einen Debugger. 6. wait: Der Prozess wartet auf ein Ereignis, üblicherweise eine Benutzereingabe 7. uninterruptible sleep: Der Prozess wartet auf ein Ereignis, üblicherweise Hardware. Tritt dieses Ereignis ein, ohne dass der anfragende Prozess es entgegennimmt, so kann das System instabil werden. 8. zombie: Der Prozess wurde beendet und aus dem Arbeitsspeicher gelöscht, aber noch nicht aus der Prozessliste entfernt Prozess Switch Grundsätzlich gilt, dass eine CPU eines Rechners ihre Rechenzeit allen laufenden Prozessen zur Verfügung stellen muss, dazu ist es notwendig von Prozess zu Prozess umzuschalten. Auslöser für das Umschalten ist immer ein systemcall oder ein Interrupt, das Umschalten mit dem Wechsel des Prozesskontextes, immer aktuell gehalten im PCB, erledigt das Betriebssystem. Seite 7(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

8 1.1.5 Schematische Interruptbehandlung schematische Interruptbehandlung, um ein Gerät zu aktivieren - Die Information über Prozesse, der sogenannte Prozesskontext, werden in der Prozesstabelle gesammelt, z.b. Befehlszähler, Stackzeiger, Speicherzuordnung, Status der geöffneten Dateien. - Bei einer Unterbrechung durch ein Gerät (z.b. die Festplatte oder ein Diskettenlaufwerk) wird die Adresse für die Prozedur zur Interruptbehandlung (InterruptServiceRoutine) aus einem gerätespezifischen Unterbrechungsvektor entnommen. - Die Unterbrechungshardware speichert den Befehlszähler, das Programmstatuswort und einige Registerinhalte. - Es erfolgt eine Verzweigung zur entsprechenden Adresse des Interrupts; ab jetzt geht es auf Softwareebene weiter - Die ISR sichert die Registerinhalte in der Prozesstabelle und speichert einen Verweis auf den entsprechenden Tabelleneintrag. - An den Bedienprozess des Geräts ergeht eine Botschaft; er wechselt vom Zustand "blockiert" in den Zustand "bereit". - Der Scheduler entscheidet, ob der Bedienprozess oder (beispielsweise) der unterbrochene Benutzerprozess aktiv wird. - Die Unterbrechungsverarbeitung stellt den Kontext des ausgewählten Prozesses her und startet ihn Prozess Modus In modernen Rechnersystemen werden zwei Prozess Modi unterschieden.: - der Kernel-Modus und - der Benutzermodus. Der Betriebssystemkern (Kernel) läuft im so genannten privilegierten Modus (auch Kernel-Modus ) und hat dort Zugriff auf den kompletten Befehlssatz der CPU und den gesamten Speicherbereich. Aus Sicherheitsgründen laufen normale Benutzerprozesse dagegen in den unprivilegierten Modus (auch Benutzer-Modus), in denen ihnen weniger Befehle zur Verfügung stehen und sie daher gewisse Aufgaben nicht direkt erledigen können. So muss also ein Benutzerprozess öfters mal den Prozessmodus wechseln, um im privilegierten Modus bestimmte Aufgaben erledigen zu können. Dies geschieht bei Unix im Prinzip wie folgt: Der Linux-Kernel hat eine Liste aller ihm bekannten Systemaufrufe, die so genannte SystemcallTabelle. Ein Systemaufruf, auch Systemcall, ist bei Betriebssystemen eine von Benutzerprogrammen benutzte Methode, um vom Betriebssystem bereitgestellte Funktionalitäten auszuführen, wie etwa das Lesen einer Datei. Dabei wird die Kontrolle vom Programm an das Betriebssystem übergeben. Jedem Systemaufruf wird dort eine eindeutige Nummer und eine kernelinterne Funktion zugeordnet, die für die eigentliche Erledigung der erforderlichen Aufgaben zuständig ist. Um einen Systemcall durchzuführen, wird die Nummer des gewünschten Aufrufs in einem Register der CPU gespeichert und anschließend wird der Softwareinterrupt 128 ausgelöst. Argumente an den Systemcall werden ebenfalls in CPU-Registern abgelegt. Dieser Softwareinterrupt (auch Exceptioninterrupt genannt) unterbricht die Programmausführung im Benutzer-Modus und erzwingt das Ausführen eines Exception-Handlers im Kernel-Modus. Dadurch wird der Kontextwechsel von einem unprivilegierten Modus gewährleistet. Der aufgerufene Exception-Handler ist eine Funktion im Kernel, die das entsprechende Register ausliest und dann, sofern sich darin eine gültige Systemaufruf-Nummer befindet, die entsprechende Kernel-Funktion aus der systemcalltable mit den in den weiteren Registern liegenden Argumenten aufruft. Nach der Überprüfung der Argumente werden letztlich die aus dem Benutzer-Modus angeforderten Aufgaben vom Kernel erledigt. Kehrt diese Funktion zurück, wird auch der Exception-Handler erfolgreich abgeschlossen und der normale Programmfluss im unprivilegierten Modus fortgesetzt. Seite 8(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

9 1.1.7 Prozesserzeugung Beispiel: Kindprozessgenerierung mit fork(), danach führen Vater und Kindprozess andere Kommandos aus, dabei ist die Reihenfolge der Ausführung nicht gesichert. Dies wird realisiert mit Programmüberlagerung, mit dem Befehl exec() dabei wird kein neuer Prozess erzeugt. #include <sys/types.h> #include <unistd.h> #include <stdio.h> int main (void) pid_t pid; char *args[4]; /* Kindprozess generieren */ if ((pid = fork()) < 0) perror("fork"); exit(1); if (pid == 0) /* dieser Code wird im Kindprozess ausgefuehrt */ execl("/bin/echo", "-e", "\t hallo heute ist", 0); /* wenn exec ok, keine Fehlermeldung */ perror("exec"); exit(2); /* dieser Code wird im Vaterprozess ausgefuehrt */ args[0] = "datum"; args[1] = "+%A, der %d. %B %Y"; //%A Wochentag - %d day - %B Monatsname %Y year args[2] = 0; execv("/bin/date", args); /* wenn exec ok, keine Fehlermeldung */ perror("exec"); exit(3); return 0; Seite 9(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

10 1.2 Prozess-Scheduling In einem Mehrbenutzersystem sollten viele Prozesse parallel laufen, aber nur eine beschränkte Anzahl von CPUs steht zur Verfügung, deshalb muss das Betriebssystem entscheiden welcher Prozessor welches Programm, wie lange und wann ausführt. Diese Entscheidung trifft ein Prozess-Scheduler mit Hilfe eines Scheduling Algorithmus. Vereinfacht: Bei einem Ein-Prozessor-System läuft zu jeder Zeit nur ein Prozess, der Rest wartet auf das Scheduling in Scheduling_queues: - die ready-queue Prozesse im Status bereit oder in - device-queues Prozesse, die auf I/O warten (pro Gerät eine Queue) Mögliche Anlässe zum Scheduling sind: - Prozess wechselt vom Zustand laufend nach blockiert (z.b.: Warten auf I/O beginnt) - Prozess wechselt vom Zustand laufend nach bereit (z.b.: wegen timer interrupt) - Prozess wechselt vom Zustand blockiert nach bereit (z.b.: Warten auf I/O beendet) - Prozess wird beendet Kriterien für Scheduling - Algorithmen: Gerechtigkeit Effizienz Antwortzeiten Verweilzeit (jeder Prozess bekommt gerechten Anteil an CPU) (CPU ist immer ausgelastet) (minimale Antwortzeit für interaktive Benutzung) (minimale Wartezeit für Stapelbenutzer) Durchsatz (maximale Anzahl bearbeiteter Aufträge pro Zeiteinheit) Die Anforderungen sind teilweise konträr (Dialogprozesse kontra Batchprozesse), das folgende Problem tritt also auf: Das Prozessverhalten ist nicht vorhersagbar, ein Prozess kann z.b. eine hohe CPU-Belegung oder viele I/O Wartezeiten haben. Lösung: Deshalb muss ein Prozess auch gewechselt werden können, wenn er nicht selbst blockiert. Dazu wird üblicherweise eine Zeitscheibe (timeslice) genutzt, die festlegt, wie lange ein Prozess den Prozessor benutzen darf. Ein Prozess wandert während seines Lebenszyklus durch die verschiedensten Zustandsund Gerätequeues. Ein Scheduler bestimmt den Zeitpunkt und die Queue aus der der nächste Prozess dem Prozessor zugeteilt wird. Unterschieden wird das Preemptive (unterbrechendes und bevorrechtigtes) Scheduling bei Dialogsystemen, wo laufende Prozesse zu jeder Zeit von einer zentralen Instanz, dem Scheduler, der Prozessor entzogen werden kann. Nonpreemptive (nicht unterbrechendes) Scheduling bei Batchsystemen, wo rechnende Prozesse nicht verdrängt werden Für allgemeine Systeme sind Nonpreemptive Scheduling Algorithmen nicht tauglich, da konkurrierende Benutzer am System sind. Bei Preemptive Scheduling Algorithmen kann ein Prozess jederzeit unterbrochen werden. Dadurch können zeitkritische Abläufe auftreten, z.b. wenn auf gemeinsamen Speicher zugegriffen wird. Semaphoren, Ereigniszähler, Monitore, Nachrichtenaustausch oder ähnliche Methoden werden vom Betriebssystem genutzt, um solche zeitkritischen Abläufe zu kontrollieren. Wichtige Größen in der Ablaufplanung sind t: die benötigte Ausführungszeit, also die reine Rechenzeit eines Prozessstücks T: gesamte oder reale Ausführungszeit inklusive Wartezeiten, die Verweilzeit W: gesamte benötigte Wartezeit(en), bis ein Prozess die gesamte benötigte CPU-Zeit bekommen hat P: Priorität Q: Zeitquantum Seite 10(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

11 1.2.1 First Come, First Serve Scheduling Das First Come, First Serve Scheduling ist der einfachste und bekannteste nonpreemptive Scheduling Algorithmus, der auch unter dem Namen First - In First - Out bekannt ist. Das Prinzip ist, der zuerst ankommende Prozess, wird auch als erster abgearbeitet. Realisiert wird dieser Algorithmus mit Hilfe einer FIFO-Warteschlange: Einfügen am Ende einer Warteschlange, Entnehmen am Anfang der Warteschlange. Angenommene Prozesssituation: Prozessname CPU-Bursts (Rechenzeiten) A 24 B 3 C 3 Ankünfte in der Reihenfolge: A, B und C Wartezeit A=0 B=24 C=27 reale Ausführungszeit A=24 B=27 C=30 damit ergibt sich eine mittlere Wartezeit von 17 und eine mittlere reale Ausführungszeit von 27 Ankünfte in der Reihenfolge: C, B und A Wartezeit C=0 B=3 A=6 reale Ausführungszeit C=3 B=6 A=30 damit ergibt sich eine mittlere Wartezeit von 3 und eine mittlere reale Ausführungszeit von 13 Nachteile: - starres Verfahren, die mittlere Wartezeit wird z.b. nicht minimiert - ungünstig bei einseitiger Prozessprofilierung: z.b. ein rechenintensiver Prozess und viele I/O Prozesse Shortest Job First Aus den Überlegungen zu FIFO ergibt sich der Scheduling Algorithmus Shortest Job First. Dieses Scheduling ist für Batch-Jobs geeignet, bei denen die Ausführungszeiten bekannt sind. Prinzip: Wenn mehrere Jobs in einer Warteschlange sind, dann nimmt der Scheduler den Job mit der kürzesten Ausführungszeit zuerst. Beispiel: In der Warteschlange sind die Jobs mit den Rechenzeiten A=8 B=6 C=4 und D=2 In SJF Reihenfolge: Jobreihenfolge Verweilzeit D 2 C 6 B 12 A 20 Mittlere Verweilzeit 10 Wenn die Jobs mit der kürzesten Ausführungszeit immer als erstes bearbeitet werden, ergibt sich eine minimale durchschnittliche Verweilzeit Notwendige Voraussetzung: alle Aufträge müssen gleichzeitig bekannt sein Seite 11(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

12 1.2.3 Round-Robin-Scheduling Das Round-Robin-Scheduling ist der älteste, am weitesten verbreitete, einfachste und fairste Scheduling Algorithmus. Prinzip jeder Prozess ist gleichwichtig: Jeder Prozess erhält ein bestimmtes Quantum (ein Zeitintervall) zum Rechnen Ein Prozess wird gewechselt, wenn: er am Ende des Quantums noch läuft er blockiert er terminiert Einreihung eines abgelösten Prozesses ans Ende der Prozessliste LaufenderProzess LaufenderProzess A B - C - D - E Dann: B - C - D - E - A RoundRobin Zeitquantum=2 Prozess Rechenzeit Verweilzeit Wartezeit A B C D Summe Durchschnitt(Rechenzeit): 9 Durchschnitt(Verweilzeit): 26,5 Durchschnitt(Wartezeit): 17,5 Problem: Wie groß ist ein optimales Quantum? Beispiel: Umschaltzeit = 5 ms Verwaltungszeit bei jedem Schalten: z.b. Sichern Prozesskontext Quantum = 20 ms insgesamt 25 ms 20 % CPU-Zeit für Administration, also ineffektive CPU Auslastung Umschaltzeit = 5 ms Quantum = 500 ms insgesamt 505 ms nur etwa 1 % CPU-Zeit für Administration, aber hohe Dialogantwortzeiten in diesem Moment => Ein sehr hohes oder ein sehr geringes Quantum sind offensichtlich nicht optimal, deshalb gilt es einen Kompromiss zu finden; ein Kompromiss wäre hier z.b. 100 ms. Seite 12(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

13 1.2.4 Prioritätengesteuertes Scheduling Ein Scheduling, das wichtige und weniger wichtige Prozesse kennt. Jeder Prozess erhält eine Priorität. Der Prozess mit der höchsten Priorität wird aktiviert. Am Ende einer Zeitscheibe oder nach einer sonstigen Unterbrechung wird u. U. die Priorität erniedrigt, da sonst immer nur die Prozesse mit anfangs hoher Priorität laufen und Prozesse mit anfangs niedriger Priorität u.u. nie zum Rechnen kommen Statische Zuordnung Prozessen können von der Administration nach der Wichtigkeit statisch Prioritäten zugeordnet werden z.b. Prioritäten nach Hierarchien (je höher der Auftraggeber in der Hierarchie steht, desto höher die Priorität seiner Prozesse) Prioritäten nach Auftragskosten (je höher das Entgelt für die Rechnernutzung, desto höher die Priorität der Prozesse) Dynamische Zuordnung Prozessen können vom System selbst unter Berücksichtigung des I/O-Anteils dynamisch Prioritäten zugeordnet werden z.b. Ziel: Jobs mit hohem I/O-Anteil erhalten eine hohe Priorität, damit sie ihre wenigen CPU-Aktivitäten sofort erledigen können Algorithmus: P = Q/f mit P=Priorität, Q=Quantum, f=anteil im letzten Quantum beanspruchter CPU-Zeit, der Prozess mit der höchsten Priorität bekommt das nächste Quantum, wird für mehrere Prozesse die gleiche Priorität berechnet, wird FIFO angewendet Beispiel1: Beispiel2: Quantum=100ms; beanspruchte CPU-Zeit im letzten Quantum=2ms => Priorität=50 (nicht viel von CPU verbraucht, weil er auf I/O gewartet hat => hohe Priorität) Quantum=100ms; beanspruchte CPU-Zeit im letzten Quantum=50ms => Priorität=2 (viel von CPU verbraucht, weil wenig auf I/O gewartet hat => niedrige Priorität) Sei folgende Prozesssituation gegeben: Beteiligt sind 4 Prozesse A, B, C, D mit den Anfangsprioritäten 50, 40, 30, 20, das Quantum sei 60 ms, die jeweiligen f=anteile der im letzten Quantum beanspruchten CPU ist gemäß der folgenden Tabelle bekannt: f 1 f 2 f 3 f(a) = 20ms 2ms und 5ms f(b) = 5ms 10ms und 10ms f(c) = 20ms 5ms und 5ms f(d) = 5ms 5ms und 5ms die Prioritäten P werden nach 4 Quanten neu berechnet, die Reihenfolge R der Prozessausführungen ergibt sich dann wie folgt: Prozess P a R a f 1 P 1 R 1 f 2 P 2 R 2 f 3 P 3 R 3 A B C D Prioritätsklassen Zusätzlich kann man Prozesse in Prioritätsklassen gruppieren und innerhalb der Klassen Round-Robin anwenden. Solange Prozesse der höchsten Prioritätsklasse da sind, werden sie zuerst ausgeführt. Dann erst Prozesse der nächste Klasse. Warteschlangen: Prioritätsklasse 4 Prioritätsklasse 3 Prioritätsklasse 2 Prioritätsklasse 1 lauffähige Prozesse ProzessN-1---ProzessN---ProzessN+1 rechenbereite Priorität ProzessM-1---ProzessM---ProzessM+1---ProzessM+2 ProzessR-1---ProzessR---ProzessR+1 ProzessQ-1---ProzessQ---ProzessQ+1 niedrigste Priorität Seite 13(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

14 Problem: bei statischen Prioritätsklassen verhungern die unteren Klassen, deshalb müssen Prioritäten von Zeit zu Zeit angepasst werden Mehrere Quantenwarteschlangen Für CPU-intensive Prozesse ist besser ein großes Quantum auf einmal als viele kleine, da somit die Anzahl der Kontextwechsel auf und von der Platte verringert wird. Diese Tatsache berücksichtigt der folgende Prioritätscheduler. Prinzip: Vorteil: Einteilung in Prioritätsklassen mit unterschiedlicher Quantenanzahl : Prozesse der höchsten Klasse erhalten nur ein Quantum, der zweithöchsten zwei Quanten, dann 4, 16 usw. Wenn die entsprechenden Quanten eines Prozesses in einer Prioritätsklasse abgelaufen sind, der Prozess aber noch nicht terminiert ist, wird der Prozess in eine niedrigere Klasse eingestuft und bekommt damit bei der nächsten Zuteilung mehr CPU. Je weiter der Prozess in untere Prioritätsklassen rutscht, umso seltener kommt er dran, bekommt aber dann mehr CPU. Reduziert für CPU-intensive Prozesse die Kontextwechsel und hält die CPU für kurze, interaktive Prozesse frei. Problem: I/O Prozesse werden bevorzugt Möglich: bei Return-Taste wieder in höchste Prioritätsklasse, da vermutet wird, dass der Prozess jetzt interaktiv wird. Ein Problem entsteht, wenn die User das herausfinden A-priori-Scheduling Beim A-priori-Scheduling wird dem Benutzer ein Versprechen über seine Performance gemacht, nämlich darauf zu achten, dass bei n Benutzern jedem Benutzer 1/n der Prozessorzeit zukommt Prinzip: Steuere Prioritäten nach der realen Anzahl der Benutzer und der verbrauchten Prozessorzeit je Benutzer. Die Zeit, die jedem zusteht, kann leicht berechnet werden: Zeit seit Sitzungsbeginn (Wartedauer) geteilt durch n (Anzahl Benutzer). Dann bekommt immer jener Benutzer den Prozessor, der am wenigsten seiner zustehenden Prozessorzeit verbraucht hat. Beispiel: n angemeldete User; jeder hat Anspruch auf 1/n der CPU-Kapazität System benötigt: Wie lange ist er schon angemeldet? Wie viel CPU-Zeit hat der Benutzer seit der Anmeldung verbraucht? Wartedauer Anspruch = n verbrauchte_ Zeit verbrauchte_ Zeit Verhältnis = = n* Anspruch Wartedauer Bei einem Verhältnis von 0,5 hat der Benutzer nur die Hälfte seiner Anspruchszeit verbraucht. Bei einem Verhältnis von 2 hat ein Prozess doppelt soviel verbraucht, wie ihm zusteht. Der Prozess mit dem kleinsten Verhältnis erhält die CPU, oder anders ausgedrückt, er hat die höchste Priorität und wird solange ausgeführt, bis es einen anderen Benutzer gibt, der ein kleineres Verhältnis hat. A = Anspruch W = Wartedauer V = Verhältnis F = verbrauchte CPU_Zeit Seite 14(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

15 Sei folgende Prozesssituation gegeben: Beteiligt sind 3 Prozesse A, B, C mit der Anfangswartedauer 3000ms, 4000ms und 6000ms, ein Quantum habe 500ms, die jeweiligen F=Anteile der im jeweiligen Quantum verbrauchten CPU ist gemäß der folgenden Tabelle bekannt: F 1 F 2 F 3 F(A) = 200ms 50ms und 300ms F(B) = 50ms 300ms und 200ms F(C) = 300ms 200ms und 50ms Prozess A Prozess B Prozess C W A F A V A W B F B V B W C F C V C , , , , , , , , , , , , , , , , , ,18 die Quantenzuteilung geschieht also für die Prozesse in der folgenden Prozesreihenfolge: B C A A B C Zweistufiger Scheduler Zweistufiges Scheduling berücksichtigt die Tatsache, dass Prozesse ausgelagert sein können. Es gibt also Prozesse im Hauptspeicher als auch Prozesse, die ausgelagert sind auf Platten. Problem Einige Prozesse müssen auf der Platte ausgelagert bleiben, da in der Regel der Hauptspeicher zu klein ist. Ein/Auslagerung auf Platte ist viel langsamer als ein Tausch von im Hauptspeicher residenten Prozessen Prinzip: verwende globalen und lokalen Scheduler lokaler: verwaltet die Prozesse im Hauptspeicher globaler: vertauscht hin und wieder Prozesse aus dem Hauptspeicher mit Prozessen auf der Platte Kriterien für globalen Scheduler: Zeitspanne, seit ein Prozess ein/ausgelagert wurde CPU-Zeit, die ein Prozess hatte Wie groß ist der Prozess? Welche Priorität hat er? Seite 15(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

16 1.2.8 Prozess-Scheduling unter UNIX Schedulingstrategie: Jeder Prozess hat beim Start eine hohe Priorität und darf in einer festen Zeitscheibe laufen. Prozesse, die in ihrer Zeitscheibe laufen, verringern kontinuierlich ihre Priorität. Prozesse, die die CPU freiwillig abgeben, behalten ihre Priorität. Die Priorität von inaktiven Prozessen, die aber laufen könnten, werden erhöht. Prozesse mit kurzen CPU - Zeiten und langen I/O - Zeiten werden bevorzugt, d.h. CPU - intensive Prozesse werden benachteiligt. Prioritäten: User priority: Kernel priority: Wertebereich: Wert bezieht sich auf die Priorität im User - Mode Wert bezieht sich auf die Priorität im Kernel - Mode 0-127, wobei einem niedrigen Wert eine hohe Priorität entspricht Der Kernel ordnet jedem Prozess, der gerade in den Schlaf gelegt wird, eine feste, mit der Ursache des Schlafens in Bezug stehende Priorität zu. Zur Verwaltung aller Prozesse gibt es ein System von Queues, in denen alle lauffähigen Prozesse geführt werden. Prozessscheduling: Multilevel - Feedback - Queues: Auswahl des Prozesses, der als nächstes laufen soll. - Scheduler durchsucht alle run - queues, von der höchsten bis zur niedrigsten Priorität und wählt den ersten Prozess aus der run - queue mit der höchsten Priorität - Round Robin RR in den run - queues bei Prozessen gleicher Priorität - Wenn ein Prozess, der gerade nicht läuft, eine höhere Priorität erreicht, als der Prozess, der gerade läuft, schaltet das System auf diesen um, falls Quantum abgelaufen ist - Die Priorität ändert sich während seiner Lebensdauer die Prozesse wandern zwischen den queues - Die Zeitgeberroutine berichtigt im Abstand von jeweils einer Sekunde die Priorität aller Prozesse im User - Mode und veranlasst anschließend den Kern den Scheduler erneut zu durchlaufen - Die Berechnung der Priorität geschieht mit Hilfe der folgenden Formel: Seite 16(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

17 Priority = ( recent CPU - Usage / 2 ) + base priority + nice-value Alterung (CPUa) nice value: Steuerparameter ( User beeinflussbar: nice-kommando ) nice dient dazu, zeitunkritische Programme mit kleinerer Priorität zu starten. Programme werden standardmäßig mit dem nice-wert 0 gestartet. In der Regel dürfen Anwender ihre Programme nur mit reduzierter Priorität starten, ausgenommen der Benutzer root. base priority: CPUa: Beispiel: Basiswert, den ein Prozess im User - Mode anfangs erhält Zähler, der nach jedem Zeitgebertick um 1 erhöht wird und am Ende eines Zyklus halbiert wird 3 Prozesse A,B,C werden gleichzeitig mit der base priority 60 erzeugt. Zeitgeber unterbricht 60 mal pro Sekunde. Das Zeitquantum sei 1sec. Die Prozesse geben keine Systemaufrufe ab und keine anderen Prozesse sind am laufen. Nach einem Quantum wird die Priorität berechnet. Zeit/Quantum A B C Priority CPUa Priority CPUa Priority CPUa Seite 17(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

18 1.3 Prozesskommunikation Zeitkritische Abläufe Prozesse müssen miteinander kommunizieren können, z.b. beim pipe wird die Ausgabe des einen Prozesses zur Eingabe des anderen Prozesses. Zusammenarbeitende Prozesse können für die Kommunikation auch gemeinsamen Speicher benutzen. Die Kommunikation zwischen den Prozessen wird Interprozesskommunikation (IPC) genannt. Mit IPC können z.b. Prozessabläufe synchronisiert werden. Wenn gleichzeitig laufende Prozesse auf gemeinsamen Speicher zugreifen, dann sind Überlappungen möglich. Verarbeitungsergebnis ist von der zeitlichen Reihenfolge abhängig. 1. Beispiel: Variablenbenutzung x=3 Prozess A A1: X=X*X A2: Write(X) Prozess B B1: X=X/2 B2: Write(X) Ergebnis ist von der Verarbeitungsreihenfolge abhängig: A1-A2-B1-B2 A=9 B=4,5 A1-B1-A2-B2 A=4,5 B=4,5 Ergebnisse hängen von der Geschwindigkeit der Prozesse ab. 2. Beispiel: Druckerspooler Wenn ein Prozess eine Datei drucken will, so wird der Name in den Spoolkatalog geschrieben. Der Druckerdämon prüft diesen Katalog, veranlasst das Drucken der Datei und entfernt danach den Dateinamen. Spoolerkatalog: frei,., frei, name(1),..., name(n), frei,., frei out = Nummer der nächsten Druckdatei in = Nummer des nächsten freien Platzes in Katalog Die Variablen in und out sind in einer Datei, dem Spoolkatalog enthalten. Auf den Spoolkatalog können alle Prozesse zugreifen. Angenommen die Prozesse A und B versuchen eine A- bzw. B-Datei auszudrucken, dann müssen sie die folgenden Verwaltungsschritte ausführen: 1. Schritt: Prozess holt sich ersten freien Eintrag in Spoolkatalog aus der Variablen in 2. Schritt: speichert den Namen der zu druckenden Datei an diesen Platz 3. Schritt: nächster freier Platz wird um 1 erhöhen 4. Schritt: und sichern nach in Zwei Prozesse A, B Prozess A A1: frei_a:=in A2: name(frei_a):=a-datei A3: frei_a:=frei_a+1 A4: in:=frei_a Prozess B B1: frei_b=in B2: name(frei_b):=b-datei B3: frei_b:=frei_b+1 B4: in:=frei_b Ein möglicher Prozessablauf: und der Spoolprozess bemerkt keinen Fehler A1-B1-B2-B3-B4-A2-A3-A4 Nur die A-Datei wird in den Spooler-Katalog aufgenommen => die B-Datei wird..nicht gedruckt Was passiert denn bei anderen Prozessabläufen? z.b.: A1-A2-B1-B2-B3-A3-A4-B4 Seite 18(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

19 Definition: 1. Eine Situation, in der mehrere Prozesse auf gemeinsame Daten lesend und/oder schreibend zugreifen, wobei die Ergebnisse vom Prozessfortschritt abhängen, heißen Wettkampfbedingungen. 2. Ein kritischer Abschnitt eines Programms ist jene Menge von Instruktionen bei der das Ergebnis ihrer Ausführung auf unvorhersehbare Weise variieren kann. Dies passiert, wenn auf Variable, auf die in diesem kritischen Abschnitt zugegriffen wird, mehreren parallel laufenden Prozessen verfügbar sind und verändert werden. daher müssen bei der Abarbeitung paralleler Prozesse die folgenden Ziele realisiert werden: - Vermeidung von Wettkampfbedingungen - Synchronisation bei der Behandlung von kritischen Abschnitten durch eine schlüssige Methode: gegenseitiger Ausschluss: d.h. höchstens ein Prozess kann zu einer Zeit auf gemeinsame Informationen zugreifen. Vier Bedingungen für effiziente Zusammenarbeit paralleler Prozesse: 1. Prozesse dürfen sich nicht gleichzeitig in ihren kritischen Abschnitten befinden 2. kein Prozess außerhalb seines kritischen Abschnittes darf andere Prozesse blockieren 3. kein Prozess darf gezwungen sein unbegrenzt lange auf ein Betriebsmittel, ein Signal oder auf den Eintritt in seinen kritischen Abschnitt zu warten 4. es gibt keine Annahmen über die relativen Geschwindigkeiten der Prozesse oder die Anzahl der Prozessoren Lösungsansätze Daher muss gefragt werden, wie kann gewährleistet werden, dass zu einer Zeit nur ein Prozess einen kritischen Abschnitt durchläuft? Dazu einige Ideen: Sperren der Interrupts Ein Prozessor wechselt nur dann zu einem anderen Prozess, wenn ein Interrupt es verlangt. Würde man alle Interrupts sperren, so kann kein anderer Prozess gemeinsame Datenbereiche mehr überschreiben. Wäre eine mögliche Lösung. Ist aber nicht so gut, weil - was passiert, wenn ein Benutzerprozess die Interruptsperre veranlasst und die Sperre von ihm nicht mehr aufgehoben wird => Benutzerprozess legt System lahm - mehrere Prozessoren da sind => die anderen Prozessoren können weiterhin gemeinsame Daten schreiben - der Betriebssystemkern sperrt auch Unterbrechungen => Kern kann jederzeit Benutzerprozess beeinflussen diese Methode des gegenseitigen Ausschlusses ist daher nicht praktikabel Verwendung einer Synchronisationsvariablen Idee: globale Variable steuert das Ausführen des kritischen Bereiches. Besitzt sie den Wert 1 wird nichts getan, bei 0 darf der eigene kritische Bereich durchlaufen werden. globale Variablen: lock; Vorbelegung: lock:=0; Seite 19(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc

20 Prozess A A1: while TRUE do begin A2: while lock=1 do A3: Wait_Read(lock); A4: lock:=1; A5: kritischer Abschnitt(A); A6: lock:=0; A7: Prozess B B1: while TRUE do begin B2: while lock=1 do B3: Wait_Read(lock); B4: lock:=1; B5: kritischer Abschnitt(B); B6: lock:=0; B7: Problem: Reihenfolge z.b. A1-A2-B1-B2-B4-B5-A4-A5... Nachdem der erste Prozess die Variable liest und feststellt, dass sie den Wert 0 hat, kann ein anderer Prozess die Verarbeitung bekommen, bevor der erste Prozess die Variable auf 1 gesetzt hat. A findet lock=0, B kommt zur Ausführung, B setzt lock:=1, A setzt lock:=1 beide gehen in den kritischen Abschnitt Abwechseln durch Aktives Warten Idee: Eine globale Variable turn, initialisiert mit 0 bestimmt, welcher Prozess in seinen kritischen Bereich eintreten darf. Falls der erste Prozess 0 kriegt, führt er seinen kritischen Abschnitt aus. Der parallele Prozess stellt ebenfalls fest turn=0, er muss warten, solange bis die Variable turn vom ersten Prozess den Wert 1 erhalten hat - das aktive Warten auf den bestimmten Wert einer Variablen. globale Variablen: turn; Vorbelegung: turn:=0; Prozess A A1: while TRUE do begin A2: while turn<>0 do A3: Wait_Read (turn); A4: kritischerabschnitt(a); A5: turn:=1; A6: NichtkritischerAbs(A); A7: Prozess B B1: while TRUE do begin B2: while turn<>1 do B3: Wait_Read (turn); B4: kritischerabschnitt(b); B5: turn:=0; B6: NichtkritischerAbs(B); B7: turn wird von A und B verschieden interpretiert; deshalb keine Reihenfolge-Probleme mehr. dennoch Probleme: A geht durch das Programm, B geht schnell durch den kritischen Abschnitt und setzt turn auf 0. A geht wieder in den nichtkritischen Abschnitt von A, turn=1. A verlässt den nichtkritischen Abschnitt und kommt nicht in den kritischen Abschnitt, da B noch in seinem nicht kritischen Bereich ist und noch nicht turn=0 gesetzt wurde A kann nicht in seinen kritischen Abschnitt, solange B in seinem nichtkritischen Abschnitt ist. Prozess A: I I kritabs nkritabs kritabs nkritabs Warten auf 0 für kritabs turn=1 turn=0 turn=1 Prozess B: I Warten auf 1 kritabs nkritabs Problem: lange nicht kritische Abschnitte Funktioniert nur, wenn beide Prozesse etwa gleich schnell sind. Zusätzlich "Aktives Warten" (ständige Abfrage (turn<>0)) kostet CPU-Zeit. Seite 20(47) Fachhochschule Frankfurt (Main) 7. Prozesse.doc