Kap3

Das Prozeßmodell in Betriebssystemen Was bringen mehrere parallele Prozesse ?
• alle ausführbaren Programme werden als sequentielle Prozesse gesehen Grundsätzliche Überlegung:
• jeder Prozeß besitzt seinen (virtuellen) Prozessor und läuft (scheinbar) kontinuierlich ab In einem Prozeß wechseln sich Berechnungen und Ein/Ausgaben ab.
Beispiel: Lesen von Daten von der Festplatte, modifizieren, dann speichern. Benötigt
• die Prozesse laufen scheinbar parallel zueinander ab. Lesen und Speichern 40 msec, die Bearbeitung 10 msec dann wartet die CPU 80 %

ihrer Zeit untätig !!!
• in Wirklichkeit aber wird der Prozessor “schnell” von Prozeß zu Prozeß geschaltet
dies macht der Scheduler (Scheduling-Algorithmus)
Multiprogramming-Grad
V=3
Vorsicht bei Ein Prozeß verbringe den Bruchteil p
D

seiner Zeit mit Warten auf Ein/Ausgabe.
a-priori-Zeitannahmen in
Prozeß
Bei n Prozessen im Speicher, ist die
V=2 Wahrscheinlichkeit, daß alle gleichzeitig
Programmen !! C
im Wartezustand sind pn.
Die CPU-Auslastung ist dann 1 - pn
V=1
B
Problem: wachsende Verzögerung V
A V=0 Zeit
bei wachsender Prozesszahl n
n–1
Vd = * k , bei n Tasks, die je k Zeit laufen und keine IO benötigen (reiner CPU-Burst)
2
Prof. W. Burkard 55 Prof. W. Burkard 56

Stichworte Stichworte

Notizen Notizen

55 56

Copyright(C) by Foxit Software Company,2005-2007

Performanceanalyse Die Realität: CPU-Bursts
Jeder Prozeß besitze 20% CPU-Nutzung ( bzw. 80% sei Warten auf I/O ) q Sobald ein Prozess eine E/A-Operation
veranlasst, wird er vom BS von der CPU
genommen, und diese einem anderen
Prozess gegeben. Der blockierte 160

20min Prozess wartet auf das Ende der reale CPU-Burst-Verteilung
15min gestarteten E/A 140

ohne dabei die CPU zu nutzen.
10min 120
10min q Ein Prozess wechselt somit ständig
zwischen Abschnitten, in denen er die 100
CPU nutzt (CPU-Bursts) und solchen, in
denen er E/A-Geräte benutzt (IO-Bursts). 80
q Beides gleichzeitig macht keinen Sinn, der
Edited by Foxit Reader

Prozess kann z.B. nicht weiterrechnen, 60
For Evaluation Only.

wenn die Daten vom Datenträger noch
40
nicht da sind!
q CPU- Bursts sind im Verhältnis zu 20
IO-Bursts sehr kurz: Dauer des
Übliche Werte liegen im Bereich weniger 0 CPU-Burst
Millisekunden, gegenüber IO-Bursts, 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 in msec
10:00h 10:32h die oft 100 mal länger sind !


Notizen Notizen
von 10:00 bis 10:10 gibt es nur einen Prozess (1 .Spalte rechte Tabelle)
von 10:10 bis 10:15 gibt es zwei Prozesse (2. Spalte rechte Tabellen)
von 10:15 bis 10:20 gibt es drei Prozesse (3.Spalte rechte Tabelle)
ab 10:20 gibt es vier Prozesse (4. Spalte rechte Tabelle)

57 58


Was ist eigentlich ein Prozeß ? ... und was ist dann ein Thread ?
• Ein Prozess ist ein einzelner sequentieller Ablauf in einem Rechner, • Bei vielen Anwendungen werden keine völlig separaten Prozesse benötigt
(ein ablaufendes Anwenderprogramm ist z.B. ein Benutzerprozess)
• Dennoch will man innerhalb der einen Anwendung parallele Handlungen ermöglichen
• Da alle Prozesse gleichzeitig stattfinden, müsste für jeden Prozess auch ein Prozessor
Was heißt das ?
vorhanden sein !?
• Alle Handlungsfäden (= Threads) sollen im gleichen Prozesskontext ablaufen, somit
• Die Anzahl der Prozesse schwankt aber im laufenden Betrieb und ist meist deutlich
ein Adressraum für alle Threads
größer als die Zahl der vorhandenen Prozessoren ! Was tun ?

Das Betriebssystem muss die vorhandenen Prozessoren auf die gegebenen Prozesse • Konsequenz: alle Threads haben zunächst uneingeschränkten gegenseitigen Zugriff auf
verteilen. Dieses Zeitmultiplexverfahren wird Scheduling genannt. ihre Objekte und teilen sich die Ressourcen (geöffnete Dateien, Variablen, Code, ... )

• Dabei wird zu bestimmten Zeitpunkten ein sogenannter Kontextwechsel durchgeführt,d.h. Wie wird das implementiert?

der Zustand des aktuellen Prozesses wird gesichert und der früher gesicherte Zustand • Einfachste Lösung: die Threads übergeben sich gegenseitig reihum die Kontrolle
eines anderen Prozesses wird wieder vom Prozessor übernommen.

(sogenanntes Coroutinen-Konzept)

• Benutzerprozesse führen Benutzeraufträge (Anwendungsprogramme) aus, Dann müssen alle Threads sich gegenseitig kennen, der Anwendungsprogrammierer muss ein
Scheduling-Verfahren implementieren bzw. berücksichtigen
Systemprozesse führen Dienste des BS aus, sind also Teil des Betriebssystems
=> schlechter Ansatz, besonders bei wachsender Thread-Anzahl
• Jeder Prozess (NICHT Thread!) läuft in einem eigenen Prozessadressraum ab. Ein
• Besser: keine Implementierung vom Anwendungsprogrammierer, sondern verfügbarer
Prozess kann nur dann auf Objekte (z.B. Variablen ...) eines anderen Prozesses
Dienst des BS. Dann werden die Umschaltzeiten zwar minimal länger, bleiben aber
zugreifen, wenn das BS entsprechende Mechanismen hierfür zur Verfügung stellt
immer noch deutlich unter dem Kontext-Switch von „richtigen“ Prozessen. Warum ?
IPC = Inter-Process-Communication


Jedes Programm hat mindestens einen Thread, bei mehreren Threads nennt
man das Multithreading.
BSp.: Word ist 3 mal geöffnet mit jeweils einem Text mit mehreren 1000 Seiten,
jedes Wort das das Wort Lehrling enthält soll automatisch in Azubi umgeändert
werden. => Die Prozesse laufen nicht parallel ab, auch wenn es so aussieht. In
Wirklichkeit wird im Millisekundenbereich gewechselt.
Notizen Notizen

59 60


... Kontextwechsel bei Threads Der Prozesskontext
Der Prozesskontext umfasst alle Informationen, die das Betriebsystem über einen
ODER: Prozess besitzt und ändert sich bei Prozessablauf ständig
Was muss das Betriebssystem tun, wenn von einem Thread auf einen anderen
Identifikatoren
umgeschaltet wird ?
• Name / ID des Prozesses
• Jeder Thread hat Daten, die wirklich nur ihm zuzuordnen sind und in keiner Weise andere • Name des Benutzers, für den der Task gerade arbeitet
Threads oder Tasks betreffen: • Name des Vaterprozesses
• Das Prozessorstatuswort, also der gesamte Prozessorzustand (Inhalt der CPU-Register) • Namen der Sohn-Prozesse
• Der Stackpointer, der auf das oberste Element im Stack (Stapel) zeigt Zustandsinformationen
• Prozessorzustand ( alle Register, nur vorhanden wenn Prozess nicht aktiv )
• Der Program-Counter, der auf die nächste auszuführende Instruktion zeigt
• Bearbeitungsstand ( Zustand des Tasks: blockiert, ready, ... )
• Diese drei Daten sind vom Scheduler zu sichern bevor der neue Thread geladen wird • Alarmzustand

• Dies kann in kürzester Zeit erfolgen, da es nur wenige Daten sind ! schnell • Beschreibung zugeordneter Objekte/Betriebsmittel

Rechte
• Zugriffsrechte auf Dateien
• Zugriffsrechte auf Speichersegmente und Seiten bei Paging
• Prozessprioritäten
Betriebsmittelkonten
• Abrechnungsdaten
• Noch verfügbare Kontingente

HERON-VERFAHREN AUF WIKIPEDIA NACHLESEN

Notizen Notizen

61 62


Einfaches Prozess-Zustands-Modell Prozesszustände

• ein Prozeß befindet sich immer in einem von drei möglichen zentralen Zuständen: aktiv / running / rechnend
• AKTIV: ein Prozessor arbeitet die Instruktionen des Programmcodes gerade ab Prozesse in diesem Zustand sind im Besitz einer CPU und laufen gerade (bei
einfachem Single-Prozessorsystem kann nur immer nur ein Task in diesem
• BLOCKIERT: BS hat Befehlsabarbeitung wg. IO gestoppt, Prozessor wurde einem anderen Zustand sein
Prozeß zugeteilt. Der blockierte Prozeß wartet auf ein (die Blockierung lösendes) Ereignis.
blockiert / wartend / blocked
• BEREIT: Prozeß könnte weiterlaufen, wartet auf Zuteilung des Prozessors durch das BS Prozesse, die darauf warten, dass eine E/A-Operation endet oder eine
sonstige Systembedingung erfüllt wird, z.B. Eintreffen einer Nachricht...
Prozeß Prozeß-Terminierung In diesem Zustand können sich stets beliebig viele Prozesse befinden.
ist
ng r-

Diese Prozesse können nicht weiterlaufen, erst muss das „erlösende“
ilu so

W
aktiv
te e s

Ereignis stattfinden

ar

zu roz

te
n
bereit / rechenbereit / ready
P

au

S

f
B

Er
Prozesse in diesem Zustand sind potentiell ausführbar, aber derzeit nicht im
h
du r-

ei
rc
ug so

Besitz einer CPU.

gn
tz es

Prozeß

is
Auch in diesem Zustand können sich stets beliebig viele Prozesse befinden.
En roz

ist
P

Prozeß-Erschaffung Diese Prozesse könnten jederzeit weiterlaufen und „hoffen“ auf CPU-
bereit Prozeß Zuteilung durch den Scheduler
ist
blockiert
Ereignis tritt ein


SEHR WICHTIG
Notizen Notizen

63 64

Erweitertes Prozess-Zustands-Modell Prozesskontrollblock (PCB)
Der PCB umfasst alle wichtigen Informationen aus dem Prozesskontext,
• das einfache Modell muss erweitert werden, wenn durch Swapping ganze Prozesse damit das Betriebssystem die einzelnen Tasks verwalten kann:
wegen Speichermangels auf die Festplatte ausgelagert werden (swap out) • PID = Process Identification
• Speicherplatz zur Sicherung des
• Bis zur erneuten Einlagerung (Swap in) kann keiner der betroffenen Threads ausgeführt Prozessorzustandes bei einem Kontextwechsel Prozessidentifikation
werden.
• Informationen über den Wartegrund,
• Zustandsübergänge von allen drei bisherigen Zuständen sind möglich ! falls der Task blockiert ist Registerzustand
(Ein- und Auslesen
• Adressrauminformationen, z.B. einen Verweis
bei Kontextwechsel)
Prozeß Prozeß-Terminierung auf die oberste Seitentabelle
ist
ng r-

• Weitere Zustandsinformationen und
ilu so

aktiv Statistiken für das Scheduling
te e s

Scheduling-Informationen

W rei
zu roz

ar gn
E
Swap out

te is
P

n
Adressrauminformationen

au
S
aktiv

f
...Seitentabelle...
B
Prozeß
h
du r-

...
rc
ug so

Prozeß ist
tz es
En roz

ist ausgelagert bereit
P

bereit Prozeß Sonstiges
ist
Prozeß-Erschaffung Ereignis tritt ein blockiert Swap in
blockiert Nächster PCB


Notizen Notizen

65 66


Dispatcher und Scheduler Zeitlicher Ablauf beim Kontextwechsel
Langzeitscheduling
zeitliche Verschränkung der Prozessbearbeitung in einem Einprozessorsystem
• Planen der Jobausführung: es sollen nur so viele Benutzer mit ihren Anwendungen
neu ins System, wie das System verkraften kann. Begrenzung der Taskanzahl Zeit

Beispiel: ftp- oder www-Server Zugangskontrolle verhindert Serverüberlastung, Prozess A Betriebssystem-Kern Prozess B
d.h. ab der n-ten Verbindung wird der Request abgewiesen
• Ausführen von nicht-interaktiv ablaufenden Jobs (Batch-Jobs) A arbeitet, hat CPU, B steht, hat keine CPU,
zu bestimmten Zeiten (z.B. nachts ...) „aktiv“ im Zustand „bereit“
Jobende

Nutzer Unterbrechung
Kurzzeitscheduling Langzeitscheduling Kurzzeitscheduling
A im Zustand bereit, BS-Kern arbeitet,
• Das „eigentliche“ Scheduling: Scheduler & Dispatcher
steht (keine CPU)

Strategie zur Zuweisung des (der) Prozessors (Prozessoren) an die Prozesse. Zuweisung CPU an B

• Der Scheduler wählt somit aus der Menge der bereiten Prozesse den nächsten B im Zustand „aktiv,
Kandidaten für die CPU anhand einer bestimmten Strategie. Unterbrechung
Läuft jetzt auf CPU
BS-Kern arbeitet
Zuweisung CPU an A
Dispacher hat CPU, aktiv
B steht, hat keine CPU,
• Die Durchführung der Zustandsübergänge selbst ist die Aufgabe des Dispatchers. A arbeitet im Zustand „bereit“
hat CPU, aktiv
• Er stellt dafür entspr. Funktionen zur Verfügung, die von anderen Teilen der
Prozessverwaltung des Betriebssystems aufgerufen werden.

Prozess A nimmt die Unterbrechung (gestrichelte Linie) nicht wahr!

Notizen Notizen

67 68


Scheduling Zielkonflikte beim Scheduling
Sind mehrere Prozesse rechenbereit, muß das Betriebsystem den Prozeß bestimmen, der Alle Scheduling-Strategien versuchen, gewisse Ziele zu verwirklichen:
als nächster die CPU erhält. s Auslastung der CPU
===> Dieser Teil des Betriebssystems wird SCHEDULER genannt. Dieses Betriebsmittel ist meistens am wenigsten vorhanden, also will man es möglichst
===> Den angewendeten Algorithmus nennt man SCHEDULING-ALGORITHMUS. effizient gebrauchen. Ziel ist 100%-ige Auslastung, (normal sind 40% - 90%)

s Durchsatz (Throughput)
zu bewältigende Aufgabe: Die Zahl der Prozesse pro Zeiteinheit, die das System abwickelt soll maximal

In Mehrbenutzer-Timesharing-Systemen mischen sich unterschiedliche Anwendungen: s Fairness
Keine Bevorzugung eines Jobs, sofern nicht ausdrücklich gewünscht
- interaktive Anwendungen, die ständig mit dem Anwender kommunizieren
s Ausführungszeit
- nicht-interaktive Anwendungen, die ständig im Hintergrund wirken (z.B. Email)
soll minimal sein. Umfasst die Zeit von Jobstart bis Ende inkl. aller Wartezeiten etc.

- Stapeljobs werden asynchron (im Hintergrund) von Anwendern angestoßen
s Wartezeit

Problem:
in der Bereit-Liste soll minimal sein. Ist als einzigste direkt vom Scheduler beeinflussbar !!!
widersprüchliche Forderungen nach Fairneß, Effizienz, Antwortzeit, Verweilzeit, Durchsatz s Antwortzeit (response time)
Merke: Zeit zwischen einer Eingabe und der Reaktion durch das System. Muss für interaktive
Anwendungen unterhalb der menschlichen Wahrnehmungsgrenze liegen.
Ein Scheduling-Algorithmus, der einen Job-Typ bevorzugt, benachteiligt andere Job-Typen
s Realzeit
(Da die CPU-Zeit endlich ist, muß die einem Anwender vermehrt gegebene Rechenzeit bei Garantierte Einhaltung der von Anwendungen vorgegebenen Realzeitanforderungen
den anderen eingespart werden)


Notizen Notizen

69 70

Prozeß Prozeß
ist
noch
Prozesszustände und Übergänge ist
nicht
Wie bekommt das BS die CPU ? nicht
existent
am Beispiel Linux / Unix mehr
existent

Ausgangslage blockiert
mit der Ausführung eines Tasks durch eine CPU übernimmt die zugehörige Erhalte Signal Warte auf Ereignis terminiert
Anwendung die Kontrolle über den Prozessor Erzeugt (fork()
Problem Prozeß
zugeteilt exit()
idle bereit aktiv ist ein
Wie kann die Systemsoftware, also die Prozesse, die das Betriebssystem entzogen
„Zombi“
darstellen, wieder die Kontrolle über die CPU bekommen?
drei Lösungen weitermachen Warte auf Eltern
gestoppt
• Die laufende Anwendung (der aktive Task) tätigt einen E/A-Zugriff. Durch diesen
Aufruf einer Funktion des Betriebssystems gelangt das BS wieder „an die Macht“.
• Der laufende Prozess gibt die CPU „freiwillig“ auf, z.B. durch den Aufruf einer • Durch Aufruf des System-Calls fork() wird vom laufenden Task (von sich selbst!) eine
Betriebssystemfunktion „Ich will/muss jetzt warten“ Kopie gezogen und in die Bereit-Liste eingetragen ( quasi „Zellteilung“ bei Prozessen )
• Ein asynchroner Hardware-Interrupt trifft die CPU und die zugehörige Service- • Dann gibt es zwei fast identische Prozesse, die beide aus dem fork()-Aufruf
Routine ist Teil des Betriebssystems zurückkehren
Erkenntnis
• Der Unterschied liegt im Rückgabewert von fork() : der Kindprozess erhält 0 zurück
• Tritt keiner der drei Fälle ein, erlangt eine Anwendung das Ausführungsmonopol und erkennt daran, dass er der „Ableger“ ist. Der Elternprozess erhält die PID des
auf der CPU. Nutzt das BS Möglichkeit 3, so haben wir preemptives Scheduling,
Kindes und kann z.B. auf das Ende (exit()-Aufruf) des Kindes warten
sonst non-preemptives Scheduling besondere Gefahr durch „schlechte
( durch waitpid(PID) )

Programme“


Notizen Notizen

71 72


Erzeugung und Vernichtung eines Prozesses
am Beispiel Linux / Unix Zombis unter Linux / Unix
• Alle Prozesse in Unix stammen direkt oder indirekt von einem einzigen Prozess ab,
Vaterprozess Kindprozess
... ... dem init-Prozess mit der PID = 1
PID = fork() PID = fork()
// Wer bin ich ? // Wer bin ich ? • Alle Prozesse stehen also in einer Hierarchie zueinander
If ( PID == 0 ) If ( PID == 0 )
{ // ich bin das Kind { // ich bin das Kind • Beim „Sterben“ eines Kindprozesses wird der Elternprozess benachrichtigt
exec(“programm.exe“) exec(“programm.exe“)
... ... • Ist beim Ende des Kindes der Elternprozess nicht mehr existent, wird init benachrichtigt
Kindprozess
exit(); Elternprozess exit(); läuft in
... ... • In der Zeit zwischen dem exit()-Systemaufruf und dem Akzeptieren der Nachricht
überspringt if das if
} } hinein darüber beim Elternprozess gelangt der Kindsprozess in einen besonderen Zustand, er
// ich bin der Vater

// ich bin der Vater wird zum Zombi
waitpid (PID); waitpid (PID);

... ... • Bleibt ein Prozess durch einen Fehler im Zombi-Zustand, kann er nur noch durch einen
System-Neustart eliminiert werden
Wann erreicht der Kindprozess das obige exit(); ? Nur bei Fehler im exec()-Aufruf !!!

Warum kann man sich beim if-Befehl den else-Teil sparen ?
Welchen Code führt der Kindprozess aus ?

Wenn der Vaterprozess auf den Kindprozess wartet redet man von
syncronen Prozessen
Wenn der Vaterprozess und der Kindprozess nicht aufeinander warten,
sondern parallel ablaufen nennt man es asyncronen Prozess

Notizen Notizen

73 74

Prozesszustände und Übergänge
am Beispiel Windows 2000 non-preemptives Monoprozessor-Scheduling
• Komplexes Modell, da Kompatibilität
zu vielen Prozessmodellen angestrebt swap out q Es gibt nur eine CPU
transition waiting
q Die Prozesse werden vom BS nicht unterbrochen, geben die CPU also
• Spezielle Ausprägungen werden in
e entweder explizit freiwillig oder implizit durch Starten einer EA-Aktivität frei
den NT-Subsystemen gekapselt l et
swap in mp wait on object
co
• Zur Erzeugung eines Tasks gibt es w ait Einfachstes Verfahren: FCFS = First Come, First Serve !
Exe
nur einen einzigen Systemaufruf preempt com cution q Teilt den Prozessor in der Reihenfolge des Auftragseingangs zu
NTCreateProcess() bei dem die ready running pl e
tes q Einfache Schlangen-basierte Implementierung: Task am Schlangenkopf erhält stets die CPU

t
ar
Initialisierung durch entspr. pre
Code und der Elternprozess st em
pt
q Kontextwechsel, wenn rechnender Task wegen EA eine blockierende BS-Funktion aufruft
sel dispatch nach Abschluss der EA wird der Task wieder an das Schlangenende eingefügt
angegeben werden kann ect

initialized standby terminated
q Kontextwechsel, wenn rechnender Task CPU „freiwillig“ aufgibt
• Das Subsystem schafft die Task wird SOFORT wieder am Schlangenende eingefügt, also sofortige Neubewerbung um CPU

geforderte Kompatibilität
reinitialized q Konsequenzen:
• Beispiel: POSIX-Subsystem mit fork(): s Hohe CPU-Auslastung kann erreicht werden
POSIX-Prozess ruft über API fork()-Befehl. Dadurch wird Nachricht über Kern an das POSIX-Subsystem
geschickt. POSIX-Subsystem ruft NTCreateProcess() auf, gibt als ElternPID rufendes POSIX-Programm s Alle anderen Kriterien werden aber nicht optimiert!
an. Vom Kern zurückgelieferter Objektschlüssel (object handle) wird dann vom POSIX-System verwaltet. s Wartezeiten hängen sehr stark von der aktuellen Lastsituation ab
D.h. alle Systemaufrufe des POSIX-Programms werden als Nachrichten zum POSIX-Subsystem
s Mittlere Wartezeit u.U. sehr schlecht und Konvoi-Effekt (siehe Folgefolien!)
gebracht, dort mit Hilfe von NT-Systemaufrufen erledigt und die Ergebnisse wieder im POSIX-Format an
das rufende Programm zurückgegeben. Gleiches gilt für die anderen Subsysteme, siehe auch Folie 19 !


Notizen Notizen

75 76


FCFS: Varianz bei der mittleren Wartezeit FCFS: Konvoi-Effekt
q Gegeben: 3 Threads mit CPU-Bursts von 24, 3 und 3 Zeiteinheiten q Konvoi-Effekt =
trotz hoher CPU-Auslastung ist die Auslastung des Gesamtsystems eher gering
q Mittlere Wartezeit , wenn CPU-Burst 24 zuerst dran ist: 17 (z.B. ms)
q Negativer Effekt, der entsteht, wenn Threads mit langen CPU-Bursts und EA-intensive
q Mittlere Wartezeit , wenn CPU-Burst 24 zuletzt dran ist: 3 (z.B. ms) Threads kombiniert auftreten.
q Kurzlaufende IO-Prozesse können nicht genügend EA-Aktivitäten anstoßen, stehen
wieder in der Warteschlange wenig nebenläufige EA im System !
(0+24+27) / 3 = 17

24 msec 3msec 3msec


3msec 3msec 24 msec (0+3+6) / 3 = 3


Durch Verlegung des großen Prozesses wird die durchschnittliche
Wartezeit von 17 auf 3 ms gesenkt.

Notizen Notizen

77 78

Kooperatives Scheduling Shortest Job First
die FCFS-Variante unter Windows 3.x die Grundlagen
q Reihenfolge wird „kooperativ“ zwischen den aktuell ausgeführten Tasks ermittelt
q Prozessorzuteilung in der Reihenfolge wachsender CPU-Bursts
q Im Zentrum steht eine für alle Anwendungen globale Ereignisschlange q Task mit dem kleinsten nächsten CPU-Burst erhält die CPU
q Grafiksystem erzeugt Ereignisse (Benutzereingaben durch Maus/Tastatur, q Gibt es davon mehrere, wird FCFS verwendet
Statusänderungen von Fenstern, ...), stellt diese an Ende der Ereignisschlange q SJF versucht offensichtlich den Konvoi-Effekt von FCFS zu eliminieren
q Auch jede Anw. kann Ereignisse über zentrale Schlange an andere Anw. „senden“ hohe Auslastung des Gesamtsystems

q Jedes Ereignis ist an bestimmten Prozess adressiert der Ereignis-Empfänger q SJF ist beweisbar optimal bezüglich der Wartezeit der Tasks!

q Scheduler wählt stets den Prozess, der am Schlangenkopf der E.-Empfänger ist q SJF minimiert die Verweilzeiten der Jobs/Tasks im System
q Konsequenz: gute Antwortzeiten sind nur möglich, wenn ALLE Anwendungen
kooperativ sind, d.h. häufig die Kontrolle an andere Anwendungen abgeben Beispiel: Job A = 8 Minuten, Job B= 6 Minuten, Job C+D je 4 Minuten

8 6 4 4 Min.
A B C D 4 4 6 8 Min.
Verweilzeiten: C D B A
A= 8 Min. A=22 Min.
B=14 Min. B=14 Min.
C=18 Min C= 8 Min.
D=22 Min.
Durchschnitt: 15,5 Min.
D= 4 Min.
12 Min.
SJF


Notizen Notizen

79 80

Shortest Job First Highest Response Ratio Next
die Probleme HRN

q SJF ist nur bedingt realisierbar !
q Warum ? die Länge des CPU-Bursts ist vorher nicht bekannt!

q Lösung: Näherungsweise Bestimmung (Approximation) der Dauer durch
q Man schätze die Antwortzeit eines Tasks
s gemessene Dauer des letzten Bursts und dessen damaliger Schätzwert q Man schätze die Bedienzeit eines Tasks
s ... und Bildung eines Mittelwertes dazwischen:
Burst geschätzt,n+1 = α * Burst gemessen,n + (1- α) * Burst geschätzt,n
q Man bilde den Quotienten Antwortzeit / Bedienzeit
s Der Faktor α liegt zwischen 0 und 1 und bestimmt, q Man wähle den Prozess mit dem größten Quotienten
welchen Einfluss der zurückliegende Burst auf die Schätzung hat
es werden Prozesse mit kurzen Bedienzeiten bevorzugt
q SJF existiert in nicht-preemptiver und preemptiver Variante

q Nicht-preemptive Variante: Während Prozess P2 läuft wird P1 rechenbereit und der die Wartezeit von Tasks mit langen Bedienzeiten werden begrenzt,

kalkulierte CPU-Burst von P1 ist kürzer als die Restlaufzeit von P2:
da bei einer ständigen Benachteiligung deren Antwortzeit zunimmt!
P1 kommt erst auf CPU, wenn der P2-Burst zu Ende ist (EA-Operation, Aufgabe der CPU)

q Preemptive Variante, Situation wie oben:
Betriebssystem entzieht sofort P2 die CPU und lässt P1 laufen.
q Noch ein Problem mit SJF: Starvation (Verhungern): bereiter Task kommt nie dran, wenn
viele kurze Prozesse im System zuströmen



Notizen Notizen

81 82

Preemptive Scheduling Verfahren

Non-preemptiv Priority-Scheduling Round-Robin
grundlegende Idee: Die Prozesse sind unterschiedlich wichtig q einfaches Scheduling-Verfahren, fair, weit verbreitet ( RR = preemptives FCFS )
und sollen daher öfter bzw. seltener die CPU erhalten. q Jeder Prozeß erhält ein Zeitintervall Rechenzeit (Quantum)
Lösung: Jedem Prozeß wird eine Priorität zugewiesen, q Nach Ablauf des Quantum wird der Prozessor entzogen und dem nächsten zugeteilt
der ausführbereite Prozeß mit der höchsten Priorität erhält die CPU q Wenn ein Prozeß blockiert oder zu Ende ist vor dem Ende des Quantums,
Problem: sehr lange CPU-Nutzung hochpriorer Prozesse, Verhungern von Jobs erfolgt ebenfalls sofort ein Prozeßwechsel ( Kontextwechsel, Contextswitch)
Lösung: dynamisches Ändern der Priorität während der Laufzeit Aging q Implizite Annahme: Alle Prozesse sind gleich wichtig!

statische Prioritätszuweisung erfolgt durch den Anwender / Administrator q Problem: Wie lange soll das Quantum sein ??? (heute üblich 10 – 20 msec)
z.B. personengebunden ( Professor - Assistent - Student )
Liste der ausführbaren Prozesse ...
dynamische Prioritätszuweisung erfolgt durch das Betriebssystem
... vor dem Kontextwechsel ... nach dem Kontextwechsel

z.B. I/O-intensive Prozesse werden in der Prioriät erhöht

Kopf der rechenbereite Proz A Proz B Proz I Proz P Proz T Proz B Proz I Proz P Proz T Proz A
Prioritätsklassen: Warteschl. Prozesse
Einteilung der Prozesse in
Prio.3 Px Pz höchste Priorität
verschiedene Klassen von Prioritäten
Prozeß nächster
==> Prioritäts-Scheduling zwischen den Klassen Prio.2 Pk Pn Ps mit Prozeß nächster
Prozeß
==> Round-Robin innerhalb der Klassen CPU mit Prozeß
Prio.1 Pa niedrigste Priorität CPU

Wenn zwischen den Prozessen umgeschaltet wird entsteht eine Wartezeit.
Je kürzer die Bearbeitungszeit ist um so häufiger muss gewechslet werden.

Notizen Notizen

83 84

Preemptives Prioritäts-Scheduling
und

dynamic priority Round Robin (DPRR) Multiple Warteschlangen
grundlegende Idee beim preemptiven Prioritäts-Scheduling: q Es gibt nur einen Hauptprozessor CPU in einem Monoprozessorsystem
wie bei der non-preemptiven Variante q Es gibt meist mehrere DMA-fähige Controller für schnelle EA-Geräte
jetzt aber neu:
q das sind letztendlich eigene, spezialisierte Prozessoren, die man als
Unterbrechung der aktuellen Prozessorzuordnung unmittelbar dann

unabhängige Betriebsmittel betrachten kann
s wenn ein neuer Task mit höherer Priorität erzeugt wird q Idee: Einrichten einer separaten Warteschlange für jeden DMA-Controller
s wenn ein deblockierter Task mit höherer Priorität erneut rechenbereit wird
q Konsequenz: Dispatching in diesem System bedeutet Umhängen von Jobs aus einer
DPRR: Warteschlange in eine andere (mit kurzen CPU-Bursts, die dazwischen liegen)
s Erweiterung von RR durch eine vorgeschaltete Stufe
s Jeder Job hat eine bestimmte Priorität CPU Hauptprozessor
s In dieser Vorstufe gibt es eine prioritätsgesteuerte Warteschlange für die Jobs
s Die Priorität der Jobs in der Warteschlange wächst nach jeder Zeitscheibe, in der
sie nicht berücksichtigt wurden DMA-Contr. EA-Festplatte 1
s Wird die Schwellenpriorität des eigentlichen RR-Verfahrens erreicht, wird der Job DMA-Contr. EA-Festplatte 2
in die Hauptwarteschlange des RR einsortiert
s Folge: RR-Verfahren wird direkt nicht verändert, aber trotzdem unterschiedliche DMA-Contr. EA-Grafikkarte
Bearbeitung der Jobs nach Systemprioritäten
DMA-Contr. EA-CDROM


Notizen Notizen

85 86

Multilevel-Scheduling

und

Multilevel-Feedback-Scheduling Zweistufiges Scheduling
q Kategorisierung der Jobs, d.h. für jede Job-Kategorie gibt es eine eigene
Warteschlange Das zweistufige Scheduling transportiert Prozesse zwischen Hauptspeicher und
Festplatte und wählt nur aus den eingelagerten Prozessen zur Ausführung aus.
q Jede Warteschlange hat ihre eigenes Scheduling-Verfahren
q Ein übergeordnetes Scheduling-Verfahren wechselt zwischen den Warteschlangen Scheduler der unteren Ebene: wählt zwischen den eingelagerten Prozessen aus
q Können Jobs bei längerer Wartezeit in eine Warteschlange höherer Priorität Scheduler der oberen Ebene: tauscht Prozesse von RAM auf DISK und umgekehrt
wechseln spricht man von multilevel-feedback scheduling
Hauptspeicher Scheduler (obere Ebene):
Prio 0 Systemprozesse
Festplatte


Prozesse lagert unter 1-4 Prozesse ein

Prio 1 Interaktive Jobs
1: a

CPU Scheduler (untere Ebene):
Prio 2 allgemeine Jobs
2: b

3: k Prozessor
Prio 3 rechenintensive 4: s wählt Prozesse aus 1-4

Jobs


Notizen Notizen

87 88

Trennung von
Strategie und Mechanismus Scheduling in Unix
q Zentrale Multilevel-Warteschlange (mit meist 256 Elementen)
Der Scheduler des Betriebssystems kennt nicht die Aufgabe eines Prozesses q Jedes Element dieser zentralen Warteschlange ist selbst wieder eine
==> er kann also auch nicht anhand der prozeßspezifischen Aufgabenstellung Warteschlange, die nach Round Robin betrieben wird
den Prozessor zuteilen ! q Scheduler verwendet Aging-Verfahren um die Benachteiligung von
Idee: Betriebssystem stellt eine Schnittstelle (System-Calls) zur Verfügung, dialogorientierten Anwendungen durch RR zu verhindern:
durch die Prozesse die Prioritäten anderer Prozesse beeinflussen können. Erhöhung (Verschlechterung!) der Priorität eines Tasks

Resultat: Der Mechanismus des Kontextwechsels bleibt weiterhin im Betriebssystem proportional zu seiner Prozessorauslastung (multilevel-feedback) d.h. Umhängen in
und den Anwendungsprozessen verborgen, ABER andere Queue

==> Anwendungsprozesse können nach eigenen Verfahren/Algorithmen die
Prozessorzuteilung steuern 0 PCB PCB q UNIX-Scheduler durchsucht Liste oben bei 0
beginnend und startet ersten gefundenen Job
1
Real time 2 PCB PCB q Jeder Task bekommt eine initiale Priorität
Beispiel:
... q Durch Warten steigt die Priorität
Ein Datenbanksystem bestehe aus einem Vaterprozeß und einer Reihe von 127 q „nice“ – Kommando erlaubt Usern ihre
Kindprozessen für diverse Einzelaufgaben (Kommunikation mit Anwendungen, 128 PCB PCB Anwendungen in der Priorität zu senken
Caching der Daten, Locking-Mechanismen, Garbage-Collection) Der Vater kann System ...
dann z.B. die Priorität der Garbage-Collection reduzieren, wenn das DB-System 177
viele Anfragen zu bearbeiten hat. 178
User ...
Prof. W. Burkard 89 Prof. W. Burkard
255 90


Notizen Notizen

89 90

Kap3

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Kap3