Betriebssysteme H.-U. Hei UniversitŠt Paderborn. Kapitel 3 Prozesse 3-1

Transkript

1 Kapitel 3 Proesse 3-1

2 3.1 Proessbeschreibung Proessbeschreibung Ein Proess ist repršsentiert durch eine speielle Datenstruktur, den Proesskontrollblock (PCB), der alle relevante Information enthšlt,.b.: Proesscharakteristika: x Proesskennung, Name des Programms Zustandsinformation x BefehlsŠhler, Stapeleiger, Registerinhalte Verwaltungsdaten: x PrioritŠt, Rechte, Statistikdaten In grš eren Sstemen kann es Hunderte von Proessen geben.daher muss effiient mit ihnen umgegangen werden. (Datenstrukturproblem) Je nach Art und Einsat des Betriebsstems ergeben sich verschiedene Mšglichkeiten 3-2

3 Verwaltung der Proesskontrollblšcke a) Einelne Skalare PCB 1 PCB 3 PCB 2 b) Konstant langes Arra PCB c) Variabel lange verkettete Folge 3-3

4 Verwaltung der Proesskontrollblšcke d) Baum e) Invertierte Tabelle Attribut i Attribut j 3-4

5 Verwaltung der Proesskontrollblšcke In der Regel effiiensteigernd: Teilmengenbildung beÿglich wichtiger Attribute (.B. Proessustand, PrioritŠt) Proesse mit gleichem Attributwert 3-5

6 Statische und Dnamische Ssteme Statische Alle Proesse sind vorher bekannt und statisch definiert Proesse werden Òam SchreibtischÓ definiert. Die PCBs werden als Programmvariable vereinbart Proesse werden fÿr eine bestimmte Anwendung realisiert. Die PCBs werden von einem Konfigurierungsprogramm einmalig ereugt. Dnamische Die Proesse werden mittels Kernoperationen ereugt und gelšscht create_process(id, initial_values) // Anlagen des Proesskontrollblocks // Initialisierung des Proesses delete_process(id, final_values) // RŸckgabe der Endwerte // Lšschen des Kontrollblocks 3-6

7 3.2 Proessumschaltung Proessumschaltung (Proesswechsel, process switching) Proessumschaltung bedeutet, dass der Proessor die Bearbeitung des aktuellen Proesses unterbricht und stattdessen die Bearbeitung eines anderen Proesses fortfÿhrt. Proesswechsel bedeutet also einen bergang von einer Befehlsfolge in eine andere. Umschalten Leerlauf AuswŠhlen Proessor? GerŠt 1 GerŠt 2 GerŠt Zeit

8 Umschalten durch Sprung Im einfachsten Fall kann man das Umschalten direkt in die Proesse ÒeinprogrammierenÓ. Es wird dann direkt u einem anderen Proess gesprungen. Damit man spšter die Arbeit am unterbrochenen Proess wieder korrekt weiterfÿhren kann, muss man sich die Stelle merken. Eine Umschaltstelle besteht also mindestens aus Fortsetaddresse (wo wurde die Arbeit unterbrochen) Sprungbefehl (wo soll weitergemacht werden) laufender Proess (p_run) Fortsetstelle um nšchsten Proess (p_next) 3-8

9 Umschalten durch Sprung Im Programm: im Ablauf: L11: L12: P1 : jmp L21 L21: P2 : jmp L11 L11 L12 P1 P2 L21 jmp L12 L22: jmp L22 : Zeit L22 FŸr bestimmte Einsatgebiete (Realeitssteme) ist die um Umschalten benštigte Zeit ein wichtiges QualitŠtsma. Das Umschalten muss daher effiient realisiert werden. Der Sprung ist die Minimallšsung 3-9

10 Umschalten allgemeiner Das Umschalten durch direkten Sprung ist wenig flexibel und daher nur nur in speiellen einfachen FŠllen anwendbar. Im allgemeinen wird das Umschalten wesentlich aufwendiger sein, da man oft nicht wei, von wo aus man wieder u dem unterbrochenen Proess urÿckkehrt (Merken der Fortsetstelle) der nšchste Proess, auf den man umschaltet, nicht immer der gleiche ist (Auswahl des nšchsten Proesses) der Proessor wesentliche Teile der Proessbeschreibung enthšlt, die nicht verloren gehen dÿrfen (Register umladen) 3-10

11 Merken der Fortsetstelle Bevor umgeschaltet wird, merkt man sich die Adresse des nšchsten ausufÿhrenden Befehls in einer dafÿr vorgesehen Variable ni (next instruction) des Proesskontrollblocks SWITCH L: p_run.ni := L // store address L in variable ni (next instruction) // in PCB of running process p_run jmp (p_next.ni) 3-11

12 Umschalten bei veršnderlichen Fortsetadressen Proess P 1 Proess P 2 Proess P 3 ni 2 := L21 L21: ni ni 1 2 ni ni 2 := L22 3 L22: 3-12

13 Proesskontext Au er dem BefehlsŠhler enthšlt der Proessor in seinen Registern eine Menge weiterer proessspeifischer Daten: Inhalte von Rechenregistern, Indexregistern etc., die den Zustand der Programmbearbeitung, also des Proesses, repršsentieren. Inhalte von Adressregistern, Segmenttabellen, Unterbrechungsmasken, Zugriffskontrollinformation etc, die die Ablaufumgebung des Proesses darstellen. Alles usammen, also die gesamte im Proessor abgelegte proessspeifische Information wird als Kontext des Proesses (process context) beeichnet. Dieser Proesskontext muss im Rahmen des Umschaltens gerettet werden und beim Fortseten des Proesses wieder restauriert werden. Sofern Daten konstant und im PCB verfÿgbar sind, kann das Retten entfallen. 3-13

14 Kontextwechsel Der Kontextwechsel ist der aufwendigste Teil des Umschaltens. Um ihn u beschleunigen, kann von der Proessor-Hardware UnterstŸtung angeboten werden: durch speielle Befehle, mit denen man einen kompletten Registersat aus dem Proessor in den Speicher schreibt und umgekehrt durch Bereitstellung mehrerer RegistersŠte (.B. 8) auf dem Proessor, so dass beim Umschalten u.u. nur das Register gešndert werden muss, das die Nummer des gÿltigen Registersates angibt Proesswechsel ist dann relativ schnell, wenn nur die Rechenregister umgeladen werden mÿssen, also die Adressierungsumgebung dieselbe bleibt. (Proesswechsel innerhalb eines Adressraums, Leichtgewichtsproesse, Threads) 3-14

15 Auswahl des nšchsten Proesses Bisher gingen wir davon aus, dass feststeht, auf welchen Proess umgeschaltet wird. Meistens ist dieser Proess nicht konstant, sondern wird um Zeitpunkt des Umschaltens ausgewšhlt: Kriterien: Nummer des Proesses (klisches Umschalten) Ankunftsreihenfolge PrioritŠt (Dringlichkeit) x x konstant veršnderlich Die Auswahl des nšchsten Proesses beeinflusst die Verteilung der Proessorleistung auf die Proesse. Auf die verschiedenen Umschaltstrategien wurde bereits in vorangehenden Vorlesungen (KMS) eingegangen 3-15

16 Auswahl des nšchsten Proesses Das Auswahlproblem lšuft darauf hinaus, dass die Proesse total geordnet sind. Der beÿglich dieser Ordnung erste Proess wird dann als nšchster (p_next) aufgegriffen. Eventuell neu ankommende Proesse werden dann gemš der Ordnung eingefÿgt. nšchster Proess ankommender Proess Einordnen AnfŸgen Folge von Proessen 3-16

17 Auswahl des nšchsten Proesses Verwendet man PrioritŠten, so kann die Ordnung auch weidimensional organisiert sein Gruppen gleicher PrioritŠt 3-17

18 Umschalten (als offene Befehlsfolge) Das Umschalten hat inwischen die folgende Form: SWITCH save context of p_run select p_next save next instruction of p_run jump to p_next.ni p_run := p_next load context of p_run Diese Befehlsfolge kann dort, wo ein Umschalten gewÿnscht ist, direkt in das Programm des Proesses eingelagert werden. 3-18

19 Umschalten als Unterprogramm Wenn es viele Umschaltstellen gibt, lohnt es sich, das Umschalten als Unterprogramm u organisieren. Werden alle Umschaltungen Ÿber ein einiges UnterprogrammgefŸhrt, so kann die Ablage der Fortsetstelle (ni) und der Sprung um nšchsten Proess entfallen. Dies ist bereits Bestandteil der Unterprogrammsprung- bw. der Return- Operation Dieser Unterprogrammsprung ist insofern ungewšhnlich, als ein Proess ein Unterprogramm aufruft, aus dem ein anderer Proess urÿckkehrt. SWITCH() save context of p_run select p_next p_run := p_next load context of p_run return 3-19

20 Automatisches Umschalten In vielen FŠllen ist es nicht mšglich oder nicht sinnvoll, Umschaltstellen expliit in die Proesse einubauen. WŸnschenswert wšre ein automatisches Umschalten. Dau benštigen wir eine Intervalluhr oder Wecker (timer), also eine Hardware- Einrichtung (E/A-GerŠt) mit den folgenden Funktionen: Vorgabe einer Frist (Stellen des ÒWeckersÓ) Unterbrechung bei Fristablauf (ÒWeckenÓ) Stellen Wecker Unterbrechung 3-20

21 Automatisches Umschalten Beim automatischen Umschalten kšnnen die Programme unveršndert bleiben. Das Umschalten wird gewisserma en von au en ausgelšst und kann u jedem beliebigen Zeitpunkt stattfinden (Unterbrechungen dÿrfen nicht abgeschaltet sein) Freiwilliges Umschalten Automatisches Umschalten UMSCHALTEN UMSCHALTEN 3-21

22 Bedingtes Umschalten Im Ablauf eines Proesses kšnnen Situationen auftreten, in denen eine Fortsetung der Bearbeitung vorÿbergehend nicht mšglich ist,.b. wenn auf einulesende Daten gewartet werden muss. Statt Òauf der Stelle u tretenó, kann der Proessor so lange andere Arbeit erledigen. Man spricht vom bedingten Umschalten, weil die Tatsache, ob umgeschaltet wir oder nicht, davon abhšngt, ob eine Bedingung erfÿllt ist oder nicht. Eine solche Bedingung kann sich in einer einfachen binšren Variable niederschlagen satisf condition test condition set condition condition no switch es reset condition 3-22

23 3.3 Umschaltverhinderung Umschaltverhinderung Beim automatischen Umschalten, das ja von einem externen Signalausgelšst wird, hat man Ort und genauen Zeitpunkt der Umschaltung nicht mehr unter Kontrolle. Dadurch kann beispielsweise ein Umschalten ausgelšst werden, wenn gerade ein (freiwilliges) Umschalten im Gange ist. Dies kann u Fehlern fÿhren WŠhrend des Umschaltens muss also verhindert werden, dass ein weiteres Umschalten ausgelšst wird. GrundsŠtlich kann es u Fehlern kommen, wenn eine Kernoperation mitten in ihrer AusfŸhrung durch eine andere Kernoperation unterbrochen wird, da Kernoperationen auf gemeinsame Datenstrukturen ugreifen. Wenn das Umschalten u jedem Zeitpunkt eintreten kann, dann ist eine beliebige verahnte AusfŸhrung von Proessen und damit auch von Kernoperationen mšglich. 3-23

24 Probleme durch verahnte AusfŸhrung In Kernoperationen gibt es eine Vielahl von Stellen, bei denen abhšngig von einer Bedingung eine Aktion durchgefÿhrt wird. Es kann nicht ausgeschlossen werden, dass wischen der Abfrage der Bedingung und der Aktion ein Umschalten stattfindet und vor der RŸckkehr um unterbrochenen Proess ein anderer Proess die Bedingung Šndert. (Beispiel: Belegung von Betriebsmitteln) Pi Pj no condition es autom. Umschalten action condition := no Die Aktion geht dann von falschen Voraussetungen aus und kann ein fehlerhaftes Verhalten bedeuten. 3-24

25 Kern als kritischer Abschnitt Kritische Abschnitte sind dann ungefšhrlich, wenn eine solche Verahnung ausgeschlossen wird. Wenn ein Proess einen kritischen Abschnitt betritt, darf kein weiterer Proess einen dau in potentiellem Konflikt stehenden kritischen Abschnitt betreten. Man spricht von einem gegenseitigen Ausschluss (mutual exclusion) Im Betriebssstemkern mÿssten alle mšglichen Konfliktstellen identifiiert und entsprechend geschÿtt werden. Da im Kern eine Vielahl dieser kritischen Abschnitte vorhanden ist, kann man es sich einfach machen und den gesamten Kern als kritischen Abschnitt auffassen. Die Konsequen ist, dass der komplette Kern unter gegenseitigen Ausschluss u stellen ist. Es muss sichergestellt werden, dass Kernoperationen nicht verahnt ablaufen kšnnen, sondern vollstšndig Òan einem StŸckÓ ausgefÿhrt werden. 3-25

26 Realisierung des Kernausschlusses Besitt der Proessor keinen Unterbrechungsmechanismus, so kann auch keine Unterbrechung der Kernoperation stattfinden. Besitt der Proessor einen Unterbrechungsmechanismus, so kann fÿr die Dauer der Kernoperation die Unterbrechungssperre gesett werden. Dadurch haben wir das Problem auf den vorigen Fall urÿckgefÿhrt. Dies gelingt aber nur bei Einproessormaschinen. Im Mehrproessorsstem kann es trot Unterbrechungsverbot u einer verahnten AusfŸhrung von Kernoperationen kommen, wenn sie eben simultan auf wei Proessoren bearbeitet werden, deren Speicherugriffe dann verahnt ablaufen. FŸr diesen Fall mÿssen wir den gegenseitigen Ausschluss am Kern durch eine sogenannte Kernsperre erwingen. 3-26

27 Kernausschluss Die Realisierung des Kernausschlusses ist offensichtlich davon abhšngig, ob Unterbrechungen mšglich sind und ob mehrere Proessoren vorhanden sind. Daher haben wir vier FŠlle u unterscheiden: Fall 1: Fall 2: Fall 3: Fall 4: Einproessorsstem ohne Unterbrechungen Einproessorsstem mit Unterbrechungen Mehrproessorsstem ohne Unterbrechungen Mehrproessorsstem mit Unterbrechungen Der Fall 1 erfordert keinerlei speielle Sicherungsma nahmen, da es keinen Anlass gibt,eine Kernoperation u verlassen kernel operation 3-27

28 Fall 2: Einproessorsstem mit Unterbrechungen Proessor Signale von Peripherie Maskenregister Unterbrechungssperre Die Kernoperation wird dann durch ein disable interrupt und enable interrupt geklammert. disable interrupt kernel operation enable interrupt 3-28

29 Fall 3: Mehrproessorsstem ohne Unterbrechungen Unteilbare Maschinenoperation Das Problem besteht (wiederum) darin, dass wischen die Auswertung einer Bedingung und die davon abhšngige Aktion andere Operationen geraten kšnnen, die die Bedingungsvariable Šndern. Um den gegenseitigen Ausschluss von Kernoperationen u gewšhrleisten, haben wir Sperroperationen eingefÿhrt, die jedoch selbst wiederum kritische Abschnitte darstellen, die unteilbar ablaufen mÿssen, d.h. die unter gegenseitigen Ausschluss u stellen sind Um diese Rekursion aufulšsen, gibt es i.d.r. einen Maschinenbefehl, der in einer unteilbaren Operation den Wert einer Bedingungsvariable abfragt und sie gleicheitig sett: test_and_set(reg, x):= {load reg, x; x:=1} UnabhŠngig von ihrem Wert wird die Variable x auf 1 gesett. War x=0, so wird x auf 1 gesett, andernfalls bleibt der Wert unveršndert bei 1. Solche Maschinenbefehle haben.t. unterschiedliche Namen (compare-and-swap, fetchand-add,..) und auch.t. unterschiedliche Semantik. Gemeinsam ist jedoch das unteilbare Abfragen und Schreiben einer Variable. 3-29

30 Fall 3: Mehrproessorsstem ohne Unterbrechungen Mit Verwendung des test-and-set-befehls kann dann eine richtige Lšsung angegeben werden: Ist die Kernsperre belegt, so wird in einer Mini-Schleife der Wert immer wieder abgefragt. Man nennt dies Òaktives WartenÓ (bus waiting). Eine solche Sperre wird auch als Òspin lockó beeichnet. Aktives Warten bedeutet eine gewisse Verschwendung von RechenkapaitŠt, kann aber toleriert werden, da Kernoperationen relativ kur sind. es kernel_lock set? set kernel_lock kernel operation reset kernel_lock unteilbare Maschinenoperation 3-30

31 Fall 4: Mehrproessorsstem mit Unterbrechungen Hier mÿssen nun beide Techniken, d.h. Unterbrechungssperre und Kernsperre gemeinsam um Einsat kommen. Dau wollen wir die folgenden drei Lšsungen diskutieren es kernel_lock set? set kernel_lock disable interrupt es kernel_lock set? set kernel_lock disable interrupt es disable interrupt kernel_lock set? set kernel_lock kernel operation kernel operation enable interrupt enable interrupt reset kernel_lock reset kernel_lock reset kernel_lock enable interrupt (a) (b) (c) 3-31

32 Diskussion der Lšsungen Lšsung A: Hier muss berÿcksichtigt werden, dass eine Unterbrechungsbehandlung ebenfalls eine Kernoperation darstellt, fÿr deren DurchfŸhrung also die Kernsperre benštigt wird. Gibt es nun direkt nach dem Seten der Kernsperre eine Unterbrechung, so wÿrde in der Unterbrechungsbehandlung vergeblich versucht, die Kernsperre u seten. Der Proess wÿrde an dieser Stelle ÒhŠngenbleibenÓ. Lšsung B Ideal wšre deshalb eine Operation, die unteilbar sowohl die Kernsperre als auch die Unterbrechungssperre sett. Leider findet man solche Operationen bei keinem Proessor. Lšsung C Es muss daher uerst die Unterbrechungssperre gesett werden und dann erst die Kernsperre. Lšsung C ist also korrekt 3-32

33 3.4 ProessustŠnde Wir hatten das Òbedingte UmschaltenÓ dau benutt, um den Proessor freiugeben, wenn der aktuelle Proess ur Zeit nicht fortgesett werden kann. In diesem Fall wird auf einen anderen Proess umgeschaltet. Nun kann dieser Proess u.u. auch nicht fortsetbar sein, weil er.b. ebenfalls auf das Ende einere/a-operation wartet. Nachdem auf ihn umgeschaltet wurde, wÿrde er sofort wieder den Proessor freigeben. So kšnnte man eine Reihe von Proessen ÒausprobierenÓ, bis man irgendwann auf einen stš t, der tatsšchlich fortsetbar ist. Um diese Suche nach einem fortsetbaren Proess u beschleunigen, fasst man die Proesse nach ihrem Zustand (fortsetbar, nicht fortsetbar) u Teilmengen usammen. Nimmt man den gerade rechnenden Proess hinu, so gelangt man u drei ZustŠnden Zustand ÒrechnendÓ (running): Proesse, die gerade auf einem Proessor bearbeitet werden Zustand ÒbereitÓ (read) Proesse, die war fortsetbar sind, aber gerade nicht bearbeitet werden Zustand ÒwartendÓ (waiting) Proesse, die nicht fortsetbar sind, weil sie auf das Eintreten einer Bedingung warten 3-33

34 ProessustŠnde und ihre bergšnge Wartend (waiting, blocked) DEBLOCKIEREN (deblock) BLOCKIEREN (block) AUFGEBEN (relinquish) Bereit (read) Rechnend (running) Aktiv ZUORDNEN (assign) 3-34

35 Zustandswechseloperationen FŸr alle ZustandsŸbergŠnge (state changes) sind entsprechende Operationen im Kern vorgesehen Aufgeben (relinquish) Freiwilliges Umschalten auf einen anderen Proess. Der bisher rechnende Proess bleibt jedoch fortsetbar, d.h. geht in den Zustand ãbereitò Ÿber. Zuordnen (assign) Aufgreifen des nšchsten Proesses aus der ÒBereit-MengeÓ ur Fortsetung auf dem Proessor. Blockieren (block) Verlassen des Proessors wegen NichterfŸllung einer Bedingung (bedingtes Umschalten). Da erst die Bedingung erfÿllt sein muss, geht der Proess in den Zustand ÒwartendÓ Ÿber. Deblockieren (deblock) Ist das Ereignis eingetreten, auf das der blockierte Proess gewartet hat, so wird er durch diesen bergang wieder in die Menge der bereiten Proesse eingefÿgt. 3-35

36 Zustandswechseloperationen Bei der DurchfŸhrung der bergšnge ist u unterscheiden: die reinen Zustandswechseloperationen, die im Rahmen des Zustandswechsels erforderlichen sonstigen Aktionen Die reinen Zustandswechseloperationen hšngen davon ab, wie die ProessustŠnde realisiert sind. Beispiel: stch_deblock (ÒstchÓ fÿr Òstate changeó) ProessustŠnde als Attribut im PCB PCB PCB Proessustand als Zugehšrigkeit u einer Liste stch_deblock waiting read SWP = sequence of read processes stch_deblock SRP = sequence of waiting processes 3-36

37 Proesswechsel als Kernoperationen Neben der nderung des Zustands (als Operation an den PCB- Datenstrukturen) muss natÿrlich auch das Umschalten stattfinden Das ÒAufgebenÓ als Kernoperation sieht dann.b. folgenderma en aus: RELINQUISH stch_relinquish(p_run) // state change of running process from running to read switch(p_run, p_next) // switch processes, i.e. save and load process context stch_assign(p_run) // state change of new running process from read to running 3-37

38 Dnamische Ssteme In dnamischen Sstemen ist die Menge der am Geschehen teilnehmenden Proesse variabel. Dnamische Ssteme kšnnen in wei Schritten entstehen: Aktivieren / Deaktivieren Ein Proess kann war definiert sein (es existiert ein PCB), Programm- und Datenbereich sind vielleicht auch schon vorhanden, aber der Proess ruht, d.h. er ist nicht aktiv. Wir unterscheiden daher wischen aktiven und nichtaktiven Proessen bergšnge wischen diesen ZustŠnden sind durch die Operationen Aktivieren und Deaktivieren mšglich. Ereugen / Lšschen In einem weiteren Schritt mÿssen wir annehmen, dass Proesse bei Sstemstart noch nicht existieren, sondern expliit ereugt und ggf. gelšscht werden mÿssen DafŸr sind die Operationen Ereugen und Lšschen vorgesehen 3-38

39 Zustandsdiagramm vollstšndig Wartend (waiting, blocked) DEBLOCKIEREN (deblock) BLOCKIEREN (block) L SCHEN (delete) DEAKTIVIEREN (deactivate) AUFGEBEN (relinquish) Nichtaktiv Nichtexistent Bereit (read) Rechnend (running) ERZEUGEN (create) Existent AKTIVIEREN (activate) Aktiv ZUORDNEN (assign) 3-39

40 3.5 Umschaltstrategien Umschaltstrategien ((Low-Level-) Scheduling) Bisher bleibt ein Proess in Bearbeitung, bis er freiwillig den Proessor aufgibt durch eine Uhr-Unterbrechung ein Umschalten erwungen wird er wegen einer nichterfÿllten Bedingung nicht weiterarbeiten kann In vielen Einsatgebieten sind nicht alle AktivitŠten (Proesse) von gleicher Wichtigkeit oder Dringlichkeit, was ur Verwendung von PrioritŠten fÿhrt. Verwendet man PrioritŠten, so mšchte man erreichen, dass u jedem Zeitpunkt der Proess mit der hšchsten PrioritŠt bearbeitet wird. Das hat ur Konsequen, dass man nicht wartet, bis eine der drei obigen Situationen eintritt, sondern ein Umschalten sofort durchfÿhrt, sobald ein Proess hšherer PrioritŠt auftaucht, d.h. ÒbereitÓ wird. Man sagt, der rechnende Proess wird durch den dringlicheren Proess verdršngt (preemption) 3-40

41 VerdrŠngungsprŸfung Die PrioritŠtsbedingung besagt, dass keiner der bereiten Proesse eine hšhere PrioritŠt besiten darf als einer der rechnenden.. Wenn wir annehmen, dass die PrioritŠtsbedingung gerade eingehalten wird und die PrioritŠten konstant sind, so kann eine Verletung nur stattfinden, wenn ein neuer Proess die Bereitmenge betritt. Nach unserem Zustandsdiagramm gibt es genau drei bergšnge in die Bereitmenge Aufgeben (relinquish) Deblockieren (deblock) Aktivieren (activate) check_preemption(p) p_run.prio < p.prio N Im Rahmen dieser Operationen ist jeweils u prÿfen, ob der gerade bereit gewordene Proess eine hšhere PrioritŠt besitt als der rechnende. Ist das der Fall, so wird auf den dringlicheren Proess umgeschaltet stch_relinquish(p_run) switch(p_run, p) stch_assign(p_run)

42 Zur ErlŠuterung der Umschaltstrategien Neuankšmmling bw. verdršngter Proess Einordnen gemš Strategie NŠchster Bereitliste (Proesskontrollblšcke) Proessoren 3-42

43 Standard-Umschaltstrategien (Siehe Vorlesung KMS) ohne VerdrŠngung mit VerdrŠngung ohne PrioritŠten mit PrioritŠten ohne PrioritŠten mit PrioritŠten BZunabhŠngig FCFS, LCFS PRIO-NP LCFS-PR, RR, FB PRIO_P BZabhŠngig SJN, HRN SRTN 3-43

44 Scheduling in Unix hšchste PrioritŠt - m : Sstemproesse : Benuterproesse geringste PrioritŠt n Round-Robin innerhalb der PrioritŠtsklassen 3-44

45 Scheduling in Unix (Sstem V) Die ZeitscheibenlŠnge liegt in der Grš enordnung von 100 msec Benuterproesse besiten eine statische BasisprioritŠt von 0, die durch ÒniceÓ erhšht, d.h. verschlechtert werden kann. Dnamische PrioritŠt jede Sekunde angepa t nach der Formel dn_prio = base_prio + recent_cpu_usage / 2 Die Proessornutung wird dabei in ÒUhr-TicksÓ gemessen Vorher wird durch recent_cpu_usage = recent_cpu_usage / 2 schrittweise ÒvergessenÓ, wie gro die Proessornutung war. 3-45

46 Scheduling in Unix (Sstem V) Starke Proessorbenutung fÿhrt u einer schlechten PrioritŠt! Warum? Rechenintensive Proesse werden ãbenachteiligtò. I/O-intensive Proesse werden bevorugt! Sie belegen den Proessor nur kur, um einen E/A-Auftrag abuseten. Man erreicht dadurch eine hohe ParallelitŠt wischen den aktiven Rechnerkomponenten (CPU und Peripherie) 3-46

47 Scheduling in Windows NT 4.0 Auch Windows NT verwendet eine verdršngende, auf PrioritŠten und Zeitscheiben beruhende Umschaltstrategie Es werden 32 PrioritŠtsklassen unterschieden: fÿr Realeitproesse 1-15 fÿr normale Proesse 0 fÿr den Leerlaufproess Die Standard-ZeitscheibenlŠnge ist bei Workstation-Sstemen 6 Einheiten, bei Server-Sstemen 36 Einheiten lang. Bei jeder Unterbrechung von der Hardware-Uhr (clock tick) wird die aktuelle ZeitscheibenlŠnge um 3 Einheiten dekrementiert. Die Uhrauflšsung ist bei Intel-Proessoren ca msec, d.h. eine Zeitscheibe ist msec bei einer Workstation und msec bei einem Server. 3-47

48 Scheduling in Windows NT 4.0 Auch NT kann dnamisch PrioritŠten anpassen: Nach Beendigung eines E/A-Auftrags, auf den der Proess gewartet hat, wird die PrioritŠt - abhšngig von der Art der E/A - um 1 bis 8 PrioritŠtsebenen erhšht (priorit boost). Nach jedem Ablauf einer Zeitscheibe wird die PrioritŠt jeweils um 1 reduiert, bis der ursprÿngliche Wert wieder erreicht ist. PrioritŠtserhšhung findet auch statt, wenn ein Proe sehr lange (3-4 Sekunden) in der Bereitliste verbracht hat. (CPU starvation) Damit wird auch das Problem der PrioritŠtsinvertierung gemildert. Au erdem gibt es bei Workstations die Mšglichkeit, die ZeitscheibenlŠnge u vergrš ern (quantum stretching): Ein Vordergrundproess (aktives Fenster) kann doppelt oder dreifach lange Zeitscheiben erhalten (12 oder 18 Einheiten) 3-48

49 Multiproessoraspekte Bei Multiproessorsstemen ist es trot der Smmetrie der Proessoren oft nicht unerheblich, auf welchem Proessor ein Proe lšuft: War er vorher (lette Zeitscheibe) auf Proessor p, so besteht die Chance, dass noch wesentliche Teile seines Adressraums im Cache von p vorhanden sind. Daher gibt es hšufig das Konept der Proessor-AffinitŠt: Der Scheduler merkt sich (im Proesskontrollblock) jeweils den von diesem Proess Òbevorugt benuttenó oder ulett benutten Proessor. Dadurch wird jedoch das PrioritŠtskonept etwas aufgeweicht: Es kann vorkommen, dass ein Proess hšherer PrioritŠt wartet, obwohl ein Proess geringerer PrioritŠt rechnet. 3-49

50 Leerlaufproblem In n mit Warteustand kšnnen alle Proesse wartend werden. Der Proessor hat keine Arbeit. Um diesen Fall elegant in das Ÿbrige Geschehen u integrieren, fÿhren wir einen Leerlauf-Proess (idle process) ein. Er muss die folgenden Eigenschaften besiten Beispiele darf nicht anhalten (klischer Proess) hat geringste PrioritŠt muss jedereit verlassen werden kšnnen (VerdrŠngung) Leere Schleife while true do; Dnamischer Stopp Falls verfÿgbar: Speialbefehl, der keinen Speicherugriff durchfÿhrt und auf externe Signale reagiert Einlagerung nÿtlicher Aufgaben PrŸfungen, Reorganisationen (garbage collection) 3-50

51 3.6 Initialisierung Wie kann ein Proess erstmalig angelaufen werden? Jeder ÒEintrittÓ in einen Proess findet Ÿber die Proedur ÒUmschaltenÓ statt. P1 P2 Umschalten Teil 1 Teil 2 Kern 3-51

52 Initialisierungsproblem Der Proess beginnt und endet im ÒKern des KernsÓ, in der Proedur ÒUmschaltenÓ p_run := p_next load context of p_run Vorspann: Umschalten Teil 2 (program of p_run) save context of p_run select p_next Nachspann: Umschalten Teil

53 Initialisierungsproblem Wir mÿssen den Proess (Proesskontrollblock, Stapel) so initialisieren, als stÿnde er mitten in der Proedur ÒUmschaltenÓ. Das Umschalten wird aber (je nach Struktur des Kerns) erst nach mehreren Proeduraufrufen erreicht. Kernoperation 1 Kernoperation 1 Umschalten 3-53

54 Proessinitialisierung Proe programm Kernop. 1 Kernop. 2 Umschalten Proe kontrollblock (PCB) BefehlsŠhler Stapelanfang Stapelende Stapeleiger : 6300 : : Stapel (stack) : 3-54

55 Erstmaliges Anlaufen eines Proesses von irgendwo her Proe programm Kernschnittstelle Umschalten bei Initialisierung gelegt 3-55

56 3.7 Kernoperationen ur Proessverwaltung Proesse Kernschnittstelle Proessverwaltung Proessinteraktion... Kernoperationen Proesswechseloperationen Datenstrukturoperationen Kern-Speicherverwaltung (bei dnamischen Sstemen) behandelt 3-56

57 Beispiel: Kernoperationen fÿr Proessverwaltung I kernel module process management; export <process operations>; import <state change operations>; procedure CREATE_PROCESS(P: process); begin {create PCB for process P;} STCH_CREATE(P) end; procedure DELETE_PROCESS(P: process); begin STCH_DELETE(P); { delete PCB of process P;} end; procedure SET_ATTRIBUTE(P: process; A: attribute; V: value); begin P.A := V end; procedure READ_ATTRIBUT(P: process; A: attribute; V: value); begin V := P.A end; 3-57

58 Beispiel: Kernoperationen fÿr Proessverwaltung II procedure RELINQUISH_PROCESS(P: process); begin STCH_RELINQUISH(P); SWITCH(P,P_NEXT); STCH_ASSIGN(P_RUN) end; procedure BLOCK_PROCESS(WP: sequence of process; P: process); begin STCH_BLOCK(WP,P); if P = P_RUN then begin SWITCH(P,P_NEXT); STCH_ASSIGN(P_RUN) end end; procedure DEBLOCK_PROCESS(WP: sequence of process; P: process); begin STCH_DEBLOCK(WP,P); { check for preemption} end; end process management. 3-58

59 Beispiel: Kernoperationen fÿr Proessverwaltung III procedure ACTIVATE_PROCESS(P: process); begin {initialie PCB and stack;} STCH_ACTIVATE(P); {check for preemption} end; procedure DEACTIVATE_PROCESS(P: process); begin if P /= P_RUN then begin case P.STATE waiting: STCH_DEBLOCK(waiting queue of P,P); read: end; {delete objects created b process P} {finish all activities of P} STCH_DEACTIVATE(P); end else begin STCH_RELINQUISH(P); {delete objects created b process P} {finish all activities of P} STCH_DEACTIVATE(P); SWITCH(P,P_NEXT) end end; 3-59