BetriebssystemeTheorie-StefanEbener Part4 Neu

Betriebssysteme Theorie
Stefan Ebener
M.A. IT-Management
SS 2012
Highest-Response-Ratio-Next (HRN)
- Ausgewählt wird der Prozess, der den höchsten Wert

(Priorität Ƞ) bzgl. Folgender Formel hat:
+ Ƞ = Wartezeit / Bedienzeit
Da der Wert einerseits von bisherigen Wartezeit, andererseits

aber auch von der geschätzten Bedienzeit abhängt, werden
kürzere Jobs bevorzugt, längere kommen aber schließlich auch
zu ihrem Recht
Beachte: Algotithmus entspricht SJF, nur das Formel um

Wartezeit erweitert wurde (SJF: Ƞ = 1/Bedienzeit)
à Vor- und Nachteile wie vorher, nur wird das Starvation-
Problem beseitigt. Algorithmus arbeitet zwar nicht optimal bzgl.
Wartezeit aber immerhin relativ? gut.
Apr-12 Stefan Ebener, Betriebssysteme Theorie 131
Round-Robin (RR)
Zuteilungs-Algorithmus mit Vorrangunterbrechung:

Prozess-Unterbrechung auch von extern unter bestimmten
Bedingungen möglich, z.B. auch Ablauf Zeitscheibe
Round-Robin:
- Verallgemeinerung von FCFS
- Prozesse werden in Reihenfolge ihrer Ankunft am Ende
Bereit-Warteschlange eingeordnet. Schlange wird zyklisch
nach FIFO abgearbeitet, wobei Prozess, die CPU entzogen
bekommen haben am Ende der Schlange wieder eingeordnet
werden
- Am weitesten verbreiteter Algorithmus mit
Vorrangunterbrechung; Vor allem bei Zeitscheiben-Verfahren

Round-Robin (RR)
Beispiel:
Prozess: Bedienzeit:
P1 8 Ø Wartezeit:
P2 4 ((16-4)+(4)+(25-8)+(24-4))/4
P3 9 = 13,25
P4 5
- Zeitscheibe sei 4 Zeiteinheiten
Zeitachse: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
RR:
SJF (mit): P1 P1 P1 P1 P2 P2 P2 P2 P3 P3 P3 P3 P4 P4 P4 P4 P1 P1 P1 P1 P3 P3 P3 P3 P4 P3
x x x x

Round-Robin (RR)
Beachte:
- Verfahren hat Vorteile von FCFS
- Ist bzgl. der Wartezeit nicht optimal, erlaubt aber eine faire und
kontinuierliche Bedienung eines jeden Prozesses
- Verbraucht allerdings mehr unnütze Verwaltungszeit, da es
häufiger zu Prozesswechsel kommen kann
+ Sollte nach Möglichkeit durch zusätzliche Hardware unterstützt
werden, dass Prozesswechsel möglichst billig werden z.B. viele
Registerbänke
- Performanz und Ø-Wartezeit hängt stark von der größe der
Zeitscheibe ab. Wird Zeitscheibe sehr groß gewählt, nähert
sich RR dem Verhalten des FCFS-Verfahrens. Zu kleine
Zeitscheibe – Overhead steigt!
Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 134

Round-Robin (RR)
Beispiel:
- 3 Prozesse der Länge 10.

- Tabelle zeigt die Anzahl der nötigen Prozesswechsel pro
Prozess bei unterschiedlichen Zeitscheibengrößen inkl.
Wartezeit an.
Zeitscheibe Prozesswechsel Ø-Wartezeit

1 9 19
3 3 19
5 1 15
10 0 6,6666

Dynamic-Priority-Round-Robin
(DPRR)
- Verfeinerung von RR
- CPU-Zuweisung geschieht zweistufig: Neu eintreffenden
Prozessen wird die CPU zunächst nicht zugeteilt. Sie müssen
sich erst hocharbeiten, indem sie startend mit Priorität 0 ihre
Priorität im Laufe der Zeit erhöht bekommen, bis Prozess
Priorität erreicht hat, die mindestens der Priorität der bereits
durch CPU bedienter Prozess entspricht
- Ab diesem Zeitpunkt bekommt Prozess auch CPU zugeteilt.
Priorität steigt aber weiterhin
- Erlaubt langen Jobs eine schnelle Verarbeitung

(DPRR)
Beispiel:
Prozess: Ankunftszeit: Bedienzeit:
P1 0 8
P2 2 4
P3 5 9
P4 9 5

(DPRR)
Rules:
- Zeitscheibe sei 3 Zeiteinheiten
- Prozess der mit CPU arbeiten darf (aber gerade nicht aktiv ist;
aktiver Prozess: kein Zuwachs), bekommt bei jedem
Prozesswechsel / Zeitscheibenablauf Prioritätenzuwachs von
2, alle die keine CPU haben von 3
- Es werden immer zunächst neue Prioritäten berechnet und
danach erst neuer aktiver CPU-Nutzer bestimt
- Gleiche Priorität zweier Prozesse = FCFS
Abarbeitungsreihenfolge (in Klammern: Zeit die Prozess nach

CPU-Entzug noch brauchen wird (Rest-Bedienzeit), dahinter
aktuelle Priorität. Fett: Prozesse, die CPU nutzen, Fett+Kursiv:
Aktiver Prozess
Last-Come-First-Served (LCFS)
- Arbeitet ohne Zeitscheibe

- Sobald Prozess initiiert und ausführungsbereit ist, wird aktiver
Prozess durch ihn verdrängt; verdrängter Prozess wird an
Beginn Warteschlange gesetzt
- Prozess läuft solange, bis er sich selbst blockiert oder durch
einen neuen Prozess verdrängt wird
- Benachteiligung nicht am Zuge gekommene Prozesse extrem

Beispiel:
Prozess: Ankunftszeit: Bedienzeit:
P1 0 8
P2 2 4
P3 5 9
P4 9 5

Zeitpunkt: CPU-Prozess: Warteschlange:
0 P1(8)
2 P2(4) P1(6)
5 P3(9) P2(1), P1(6)
9 P4(5) P3(5), P2(1), P1(6)
14 P3(5) P2(1), P1(6) P4 fertig
19 P2(1) P1(6) P3 fertig
20 P1(6) P2 fertig
Ø Wartezeit: ((20-2)+(19-5)+(14-9)+0)/4 = 9,25
Die Ø Wartezeit ist nur deshalb so kurz, weil nach relativ kurzer Zeit keine neuen Prozesse mehr
ins System gekommen sind

Weitere Scheduler:
Multilevel Queue

Weitere Scheduler:
Multilevel Feedback Queue

Multilevel Feedback Queue
- Mehrstufiges Scheduling mit Rückkopplung wird bestimmt

durch:
+ Anzahl von Bereit-Warteschlange
+ Scheduling-Algorithmen für die Warteschlangen
+ Entscheidungsmethoden für Prozesswechsel (in Schlange
höherer oder niedrigerer Priorität)
+ Scheduling-Algorithmus auf Ebene der Warteschlange
• Methode zur Einordnung neu ankommender Prozesse in
Warteschlange
+ Verfahren mit höchster Flexibilität
+ Verfahren mit höchster Komplexität

Earliest Deadline First
- Echtzeit-Betriebsysteme verwenden oft das Earliest-Deadline-

First Verfahren: es wird derjenige Prozess zum Rechnen
ausgewählt, der am nächsten an seinem zeitlichen Limit ist.
- Vereinfachtes Beispiel:
+ Deadlines: T1=T2=10msec, T3=15,4msec
+ Ausführungszeiten: T1=1msec, T2=5msec, T3=5,5msec

Prozesse und Threads
Threads
Threads
- Multitasking erlaubt es, mehrere Prozesse gleichzeitig

auszuführen, scheinbar oder tatsächlich.
- Um nun in einem Prozess mehrere parallele Abläufe zu
erzeugen, führt man Threads (Ablauffäden) ein:
+ ein Thread ist ein sequentieller Ablauf in einem Prozess
+ ein Prozess kann aus mehreren Threads bestehen (parallele
Abläufe)
+ die Threads teilen sich einige Betriebsmittel (Codesegment,
Datensegment, Dateizeiger), andere werden für jeden Thread
individuell angelegt (Stack, Statusinformationen).
- Prozesse müssen Multithreading fähig sein, um mehrere CPU-

Kerne gleichzeitig nutzen zu können.

Elemente von Prozessen und Threads
* genauer: Stackzeiger
(Bei Verwendung höherer Programmiersprachen:

lokale Variable sind pro Thread, globale pro Prozess definiert)

Trennung der Aspekte
- Prozess: Einheit des Ressourcenbesitzes und des Schutzes

- Thread: Einheit der Ausführung (Prozessorzuteilung)
+ Auch: Ausführungsfaden, leichtgewichtiger Prozess
- Innerhalb eines Prozesses sind ein oder mehrere Threads
möglich

Motivation für Threads
Vorteile bei der Nutzung mehrerer Threads in einer Anwendung:
- Bei Blockierung eines Threads durch E/A: andere können

weiterarbeiten
- Kürzere Reaktionszeit auf Benutzereingaben
- Bei Rechnern mit mehreren CPUs (oder Hyperthreading):

echte parallele Abarbeitung der Threads möglich
- Nebenläufige Programmierung möglich: mehrere

Kontrollflüsse

Beispiel: Textverarbeitung
- Textverarbeitungsprogramm mit drei Threads:
Quelle: Tanenbaum, A., Moderne Betriebssysteme

Beispiel: Webserver
Ein Webserver mit mehreren Threads
Quelle: Tanenbaum, A., Moderne Betriebssysteme

Implementation
- Threads können als Kernel-Threads (verwaltet durch das BS,

präemptiv) oder User-Threads (verwaltet im Prozess,
kooperativ) ausgeführt werden. Die Realisierung hängt
letztendlich vom verwendeten BS ab.
- User-Thread Bibliotheken stehen unter vielen
Betriebssystemen zur Verfügung, aber auch Interpreter
können User-Threads unterstützen.
+ Windows
+ Linux
+ Solaris
+ Java VM
- Dabei unterscheidet sich die Benennung der User-Threads je

nach Implementierung.
Windows
- Threads werden als Kernel-Threads realisiert, ein Prozess

kann mehrere Threads besitzen, besteht aber mindestens aus
einem Thread.
- Threads werden über Systemaufrufe erzeugt.
- Das Scheduling in Windows NT erfolgt ausschließlich über

Threads, ein Thread kann selbst wieder Threads erzeugen.
- User Threads werden durch Bibliotheken der verwendeten

Programmierumgebung realisiert. Sie laufen dann unter der
Steuerung des jeweiligen Prozesses, nicht des
Betriebssystems

Prioritäten in Windows-Systemen
Quelle: Dr. Hellbrück, H., Betriebssystemen / Informatik II, Universität Lübeck

Unix-artige Betriebssysteme
- Implementierung sowohl als Kernel-wie auch als User-

Threads.
- Werden Kernel-Threads verwendet, ist die Portierung solcher

Programme auf andere Systeme schwierig bis nicht möglich.
- Einige BS, z.B. Solaris, bieten die Möglichkeit, wahlweise

Kernel-oder User-Threads zu benutzen. User-Threads sind
dann häufig als POSIX-Threads realisiert.
- Linux kannte lange keine Threads, d.h. nach seiner Erzeugung

wurde ein Thread wie ein Prozess behandelt. Seit dem Kernel
2.6 sind "echte" Threads möglich.

Beispiel:
Sequentielle Abarbeitung:
while(true)
{
DoSomething(); // irgendwas berechnen
if(QueryEvent()) // ist ein Ereignis angekommen?
{
e = ReceiveEvent(); // dann Ereignis abholen
ProcessEvent(e); // und bearbeiten
}
} // und wieder von vorne
- Verzahnung von Berechnung und Ereignisbehandlung

- Polling von Ereignissen

Beispiel:
Nebenläufige Abarbeitung
…
pthread_create(&p1, NULL, thread_1, *arg1);
pthread_create(&p2, NULL, thread_2, *arg2);
…
- Einfacherer Code
- Komplexere Vorbereitung und Koordination
Prozessinteraktion
Prozess-Interaktion
- Kommunikation (Interprozesskommunikation, IPC)

+ Daten eines Prozesses zu einem anderen bringen
+ Sicherstellen, dass zwei Prozesse sich nicht in den Weg
kommen, wenn sie auf dieselbe Ressource zugreifen wollen
+ Sicherstellen, dass eine Reihenfolge eingehalten wird. (Ein
Prozess produziert Daten und ein anderer druckt sie)
- Sonderfall: Synchronisation
+ Steuerung der zeitlichen Reihenfolge von Aktivitäten (meist:
Zugriffe auf gemeinsame Ressourcen)
+ Problem: Verklemmungen (Deadlocks) durch zyklische
Wartebeziehungen

Prozess-Kommunikation
- Bei Multitasking-Betriebssystemen spielt die Kommunikation

bzw. Synchronisation zwischen den quasi parallel ablaufenden
Prozessen bzw. Threads eine herausragende Rolle.
- -Die Gründe dafür sind vielfältig:
+ Zum einen werden größere Softwaresysteme häufig als Systeme
mit mehreren kooperierenden Prozessen gestaltet. Diese müssen
normalerweise in ihren Abläufen synchronisiert werden. Ferner
müssen häufig Daten von einem Prozess zum anderen
transferiert werden.
+ Ein anderer Grund liegt im Problem der kritischen Abschnitte von
Prozessen beim Zugriff auf nicht gemeinsam benutzbare
Betriebsmittel. Auch hier sind Synchronisationsmethoden
erforderlich, die den gegenseitigen Ausschluss gewährleisten.

- Selbst bei sehr einfachen Betriebssystemen ist eine IPC

notwendig, da zumindest eine Kommunikation zwischen einem
Prozess und dem Scheduler möglich sein muss.
- Einige Möglichkeiten der Prozesskommunikation sind:
+ Kommunikation über gemeinsame Speicherbereiche: Prozesse
können gemeinsame Datenbereiche, Variablen etc. anlegen und
gemeinsam nutzen.
+

- Weiter Möglichkeiten der Prozess-Kommunikation sind:

+ Kommunikation über Signale: Signale sind asynchron auftretende
Ereignisse, die eine Unterbrechung bewirken (Interrupt). Sie
dienen in der Regel zur Kommunikation zwischen BS und
Benutzerprozess
+ Kommunikation über Nachrichten (Ereignisse, Messages):
Nachrichten werden vom BS verwaltet. Dieses stellt eine für die
beteiligten Prozesse gemeinsam nutzbare Transportinstanz (z. B.
"Mailbox") zur Verfügung. Auf diese greifen die Prozesse über
bestimmte Transport-Funktionen des BS (Systemaufrufe) zu.
• Prozess A sendet z. B. eine Botschaft an Prozess B, indem er sie in
der Mailbox ablegt (send(message);).
• Der Prozess B holt die Nachricht dann von der Mailbox ab
(receive(message);).

- Weitere Möglichkeiten der Prozess-Kommunikation sind:

+ Kommunikation über Streams: Streams ermöglichen die
Kommunikation über Rechnernetze. Logisch gesehen haben
Streams dieselbe Aufgabe wie die lokalen Pipes.
+ Kommunikation über Prozedur-Fernaufrufe (remote procedure
call, RPC)Ein Prozess ruft eine in einem anderen Prozess
angesiedelte Prozedur auf (also über seine Adressgrenzen
hinweg). Besonders für Client-Server-Beziehungen geeignet.

Prozess-Synchronisation
- In Multitasking-Betriebssystemen teilen sich verschiedene

Prozesse in der Regel gemeinsame Betriebsmittel. Bei
gleichzeitigem Zugriff zweier Prozesse auf diese Betriebsmittel
kann es zu Inkonsistenzen der Daten kommen, die u. U. selten
auftreten und sehr schwer aufzuspüren sind.
- Kooperierende nebenläufige Prozesse müssen daher wegen

der zwischen ihnen vorhandenen Abhängigkeiten miteinander
synchronisiert (koordiniert) werden. Prinzipiell lassen sich zwei
Klassen von Abhängigkeiten unterscheiden:
+ Die Prozesse konkurrieren um die Nutzung gemeinsamer,
exklusiv nutzbarer Betriebsmittel.
+ Die Prozesse sind voneinander datenabhängig.

- Ohne eine solche Synchronisation entstehen Datenverluste,

z.B. in folgenden Fall:
+ Prozess A und B lesen ein Datenelement im Zustand X(0).
+ A schreibt es mit dem Wert X(1) zurück,
+ danach schreibt B seinen Wert X(2) zurück.
+ Damit bleibt die Änderung X(0) nach X(1) aus dem Prozess A
unberücksichtigt.
- Solche Situationen heißen zeitkritische Abläufe.

Programmabschnitte, die auf gemeinsam benutzte Daten
zugreifen, heißen kritische Abschnitte.

- Vier Bedingungen für eine gute Lösung (nach Tanenbaum):

+ Höchstens ein Prozess darf sich in einem kritischen Abschnitt
aufhalten (Korrektheit).
+ Es dürfen keine Annahmen über Ausführungsgeschwindigkeit
und Anzahl der Prozessoren gemacht werden.
+ Kein Prozess, der sich in einem kritischen Abschnitt befindet, darf
andere blockieren.
+ Kein Prozess soll unendlich lange warten müssen, bis er in einen
kritischen Bereich eintreten darf.
- Die letzten beiden Punkte dienen der Stabilität, sie sollen eine
Prozessverklemmungen verhindern.

Exkurs: Petri-Netze
- Petri-Netze sind „bi-partite Graphen“, d.h.
es gibt zwei unterschiedliche
Knotentypen, Stellen und Transitionen,
wobei jeweils nur Knoten
unterschiedlichen Typs durch eine
gerichtete Kante direkt miteinander
verbunden werden dürfen.
- Durch Marken (auch „token“ genannt), die
wie „Spielsteine“ auf den Stellen platziert
werden, entsteht ein dynamisches
Modellverhalten.
- Petri-Netze dienen als Modelle für
nebenläufige1 und nicht-deterministische
Prozesse. Sie sind nützlich für Entwurf,
Beschreibung und funktionale Analyse
komplexer Systeme.

Exkurs: Petri-Netze
Schalten von Transitionen: Ein Ereigniseintritt ist gleichbedeutend mit dem Schalten
der Transition, auch Feuern genannt. Jeder Eingangsstelle wird dann eine Marke
entnommen und in jede Ausgangsstelle wird eine Marke abgelegt (wobei einfache Kanten
vorausgesetzt sind).

Exkurs: Petri-Netze

Erzeuger/Verbraucher-Modell
- Der Produzent produziert eine bestimmte Ware, legt diese in einem Pufferbereich ab, der
Konsument entnimmt dem Puffer eine Ware und verbraucht diese.
- Die Anfangsmarkierung (0,1,0,1,0) bedeutet, dass je ein Produzent und ein Konsument existieren.
- Der Puffer (Stelle S3) ist leer. Dieses Beispiel ist auch als Erzeuger/Verbraucher-Modell bekannt.

- Übung

Erzeuger/Verbraucher-Modell

Kritischer Abschnitt

Semaphore
- Eine Lösung des
Synchronisationsproblems liefern
Semaphore (abgeleitet von einem
maritimen Flagen-Signal-System).
- Für jede zu schützende Datenmenge
wird eine Variable (binäre Variable
oder nicht-negativer Zähler).
- Ein Semaphor (Sperrvariable,
Steuervariable) signalisiert einen
Zustand (Belegungszustand, Eintritt
eines Ereignisses) und gibt in
Abhängigkeit von diesem Zustand
den weiteren Prozessablauf frei oder
versetzt den betreffenden Prozess in
den Wartezustand.

Semaphore
- Beim Bemühen um unteilbare Ressourcen (z. B. den Prozessor) wird
eine binäre Variable verwendet, bei n Teil-Ressourcen (z. B.
Arbeitsspeicher-Segmente oder Plätze in einem Puffer) kommen
Werte von 1 bis n vor. Die binären Semaphore werden auch Mutexe
(von "Mutual exclusion") genannt, jene vom Typ Integer auch "Zähl-
Semaphore".
- Semaphore für den gegenseitigen Ausschluss sind dem jeweiligen

exklusiv nutzbaren Betriebsmittel zugeordnet und verwalten eine
Warteliste für dieses Betriebsmittel. Sie sind allen Prozessen
zugänglich.
- Semaphore für die Ereignissynchronisation zweier voneinander

datenabhängiger Prozesse sind diesen Prozessen direkt zugeordnet.
Sie dienen zur Übergabe einer Meldung über das Ereignis zwischen
den Prozessen.
Semaphore - DB
- Der Schreibprozess
"Writer" darf nur dann
schreibend auf eine
Datenbasis zugreifen,
wenn zur selben Zeit
kein Leseprozess
"Reader" darauf
lesend zugreift.
- Die Leserzähler-
variable "RC"
speichert dabei die
Anzahl der aktiven
Leseprozesse. Der
Zugriff auf diese
Variable soll
synchronisiert erfolgt.

Philosophen-Problem
Fünf Philosophen sitzen rund um

einen Tisch. Vor jedem
Philosophen steht eine Schale
mit Reis und es liegen fünf
Stäbchen (hier: Gabeln) auf dem
Tisch, eine zwischen je zwei
Schalen. Jeder Philosoph
benötigt zum Essen zwei
Stäbchen (hier: "seine" und die
seines rechten Nachbarn).

Philosophen-Problem
- Aufgabe: Entwerfe einen dezentralen Algorithmus, der den

Zugriff auf die Gabeln regelt, so dass kein Deadlock auftritt
und keiner der Philosophen ausgehungert wird. Die
Philosophen verhalten sich völlig identisch.
- Typische Lösungsversuche sind oft deadlock-trächtig,

insbesondere wenn die Gabeln nacheinander angefordert
werden.
+ Versuch 1: „Greife rechte Gabel und warte bis die linke Gabel
frei wird“ ... führt zum Deadlock.
+ Versuch 2: „Greife rechte Gabel; falls linke Gabel frei, dann
ergreife sie, sonst lege rechte Gabel wieder zurück“ ... kann zum
Livelock führen.

Philosophen-Problem

Philosophen-Problem
Mit binären Semaphoren!

Philosophen-Problem

Philosophen-Problem

Weitere Mechanismen
- Monitor ist ein Mechanismus zur Steuerung eines

ausschließenden Zugriffs auf Daten. Im Monitor werden die
von Prozessen gemeinsam genutzten Daten und ihre
Zugriffsprozeduren (oder Methoden) zu einer Einheit
zusammengeführt sind.
- Lock-Mechanismen dienen der Sperre des Zugriffs von

anderer Seite während einer laufenden Bearbeitung,
beispielsweise File-Locking beim Schreiben in eine Datei. Ein
Lock kann z.B. mit Hilfe des Schedulers realisiert werden, der
einem konkurrierenden Prozess so lange keine Rechenzeit
zuweist, bis die Bedingung für den Lock entfallen ist

Monitor in C++
int x = 1;
Object^ o = x;
Monitor::Enter(o);
try
{
// Code that needs to be protected by the monitor
}
finally
{
// Always use Finally to ensure that you exit the monitor
Monitor::Exit(o);
}
Details auf: http://msdn.microsoft.com/en-us/library/hf5de04k.aspx#Y131

Deadlocks
Deadlock vs. Livelock
- Am Beispiel Petri-Netz:

Problem: Deadlock
- Eine Menge von Prozessen befindet sich in einem Deadlock-

Zustand (Verklemmungs-Zustand), wenn jeder Prozess aus
der Menge auf ein Ereignis wartet , das nur ein anderer
Prozess aus dieser Menge auslösen kann (z.B. Freigabe einer
Ressource).
- Das bedeutet:
+
+
+

Deadlock

Deadlock

Problem: Livelock
- Er bezeichnet eine Art des Deadlocks von zwei oder mehr

Prozessen, die im Unterschied zum Deadlock nicht in einem
Zustand verharren, sondern ständig zwischen mehreren
Zuständen wechseln, aus denen sie nicht mehr entkommen
können.
- Das bedeutet:
+
+
+

Bedingungen für einen
(Ressourcen-)Deadlock
1. Wechselseitiger Ausschluss:
+ Jede Ressource kann zu einem Zeitpunkt von höchstens einem
Prozess genutzt werden.
2. Hold-and-Wait (Besitzen und Warten):
+ Ein Prozess, der bereits Ressourcen besitzt, kann noch weitere
Ressourcen anfordern.
3. Ununterbrechbarkeit (kein Ressourcenentzug):
+ Einem Prozess, der im Besitz einer Ressource ist, kann diese
nicht gewaltsam entzogen werden.
4. Zyklisches Warten:
+ Es gibt eine zyklische Kette von Prozessen, bei der jeder Prozess
auf eine Ressource wartet, die vom nächsten Prozess in der
Kette belegt ist.

Bedingungen für einen Deadlock
- Bedingungen (1)-(3) sind notwendige Bedingungen, aber nicht

hinreichend. Bedingung (4) ist eine potentielle Konsequenz
aus (1)-(3)
- Die Unauflösbarkeit des zyklischen Wartens ist eine Folge aus

(1)-(3)
- Alle vier Bedingungen zusammen sind notwendig und

hinreichend für eine Verklemmung
- Konsequenz: wenn eine der Bedingungen unerfüllbar ist,

können keine Deadlocks auftreten

Beispiel

Beispiel:

Beispiel:

Beispiel:

Behandlung von Deadlocks
- Vogel-Strauß-Algorithmus
+
- Deadlock-Erkennung und -Behebung

+
- Deadlock-Avoidance(Deadlock-Vermeidung)
+
- Deadlock-Prevention(Deadlock-Verhinderung)
+
Achtung: Unterscheidung von Verhinderung bzw. Vermeidung

Zusammenfassung: Deadlock
- Deadlock: Gruppe von Prozessen wartet zyklisch auf andere

Prozesse der Gruppe
- Problem in jedem Betriebssystem (und jeder nebenläufigen
Anwendung)
- Praktikable Gegenmaßnahmen:
+ Erkennung und Abbruch eines Prozesses (z.B. bei Datenbank-
Transaktionen)
+ Deadlock-Avoidance (vorsichtige Ressourcen-Zuteilung: nur
dann, wenn dadurch garantiert kein Deadlock entsteht)
+ Deadlock-Prevention
+ Spooling: vermeidet wechselseitigen Ausschluss
+ Festlegen einer Belegungs-Ordnung auf den Ressourcen

BetriebssystemeTheorie-StefanEbener Part4 Neu

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BetriebssystemeTheorie-StefanEbener Part4 Neu

Hochgeladen von

Copyright:

Verfügbare Formate

Betriebssysteme Theorie

- Ausgewählt wird der Prozess, der den höchsten Wert

Da der Wert einerseits von bisherigen Wartezeit, andererseits

Beachte: Algotithmus entspricht SJF, nur das Formel um

Zuteilungs-Algorithmus mit Vorrangunterbrechung:

Apr-12 Stefan Ebener, Betriebssysteme Theorie 132

- Zeitscheibe sei 4 Zeiteinheiten

Apr-12 Stefan Ebener, Betriebssysteme Theorie 133

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 134

- 3 Prozesse der Länge 10.

Zeitscheibe Prozesswechsel Ø-Wartezeit

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 135

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 136

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 137

Abarbeitungsreihenfolge (in Klammern: Zeit die Prozess nach

- Arbeitet ohne Zeitscheibe

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 140

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 141

Ø Wartezeit: ((20-2)+(19-5)+(14-9)+0)/4 = 9,25

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 142

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 143

Multilevel Feedback Queue

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 144

- Mehrstufiges Scheduling mit Rückkopplung wird bestimmt

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 145

- Echtzeit-Betriebsysteme verwenden oft das Earliest-Deadline-

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 146

- Multitasking erlaubt es, mehrere Prozesse gleichzeitig

- Prozesse müssen Multithreading fähig sein, um mehrere CPU-

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 148

(Bei Verwendung höherer Programmiersprachen:

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 149

- Prozess: Einheit des Ressourcenbesitzes und des Schutzes

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 150

Vorteile bei der Nutzung mehrerer Threads in einer Anwendung:

- Bei Blockierung eines Threads durch E/A: andere können

- Kürzere Reaktionszeit auf Benutzereingaben

- Bei Rechnern mit mehreren CPUs (oder Hyperthreading):

- Nebenläufige Programmierung möglich: mehrere

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 151

- Textverarbeitungsprogramm mit drei Threads:

Quelle: Tanenbaum, A., Moderne Betriebssysteme

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 152

Ein Webserver mit mehreren Threads

Quelle: Tanenbaum, A., Moderne Betriebssysteme

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 153

- Threads können als Kernel-Threads (verwaltet durch das BS,

- Dabei unterscheidet sich die Benennung der User-Threads je

- Threads werden als Kernel-Threads realisiert, ein Prozess

- Threads werden über Systemaufrufe erzeugt.

- Das Scheduling in Windows NT erfolgt ausschließlich über

- User Threads werden durch Bibliotheken der verwendeten

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 155

Quelle: Dr. Hellbrück, H., Betriebssystemen / Informatik II, Universität Lübeck

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 156

- Implementierung sowohl als Kernel-wie auch als User-

- Werden Kernel-Threads verwendet, ist die Portierung solcher

- Einige BS, z.B. Solaris, bieten die Möglichkeit, wahlweise

- Linux kannte lange keine Threads, d.h. nach seiner Erzeugung

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 157

- Verzahnung von Berechnung und Ereignisbehandlung

Apr-12 Stefan Ebener M.A., Betriebssysteme Theorie 158

- Kommunikation (Interprozesskommunikation, IPC)