Sie sind auf Seite 1von 12

Betriebssysteme 1

Vortragender: Udo Payer

1 /12

Fragenausarbeitung zu Betriebssysteme 1
[alle Angaben ohne Gewhr, von Studenten ausgearbeitet]

#01 THREADS {02.02.2001} Betrachten Sie ein System in dem es ein 1:1 mapping zwischen User-Level-Threads und Kernel-Level-Threads gibt. Dieses System erlaubt es einem oder mehreren Threads eines Prozesses blocking System-Calls aufzurufen, whrend andere Threads weiterlaufen. a) Erklren Sie, warum unter obigen Annahmen multithreaded-Programme auf einer Einprozessormaschine schneller abgearbeitet werden knnen als single threaded Programme b) Erklren Sie den Begriff "Jacketing" Theorie: (Quelle: Folien, Chapter 04) ULT (User Level Thread): Fr den Kernel (das Betriebssystem) nicht sichtbar. Vorteil: Thread-Scheduling individuell whlbar, luft auf jedem Rechner Nachteil: wenn ein Thread blockiert (I/O Request), blockiert das OS den gesamten Prozess KLT (Kernel Level Thread): Thread-Verwaltung durch den Kernel. Vorteil: ein Thread blockiert gesamter Prozess wird nicht blockiert, Aufteilung von einzelnen Threads desselben Prozesses auf mehrere CPUs mglich Nachteil: Scheduling Verfahren fr alle Applikationen gleich. Antwort: 1:1 mapping ULT / KLT: Jeder ULT existiert auch als KLT. a) multi-threaded schneller als single-threaded Obwohl die Aufteilung auf mehrere Prozessoren hier nicht genutzt werden kann (Einzelprozessormaschine), bringt multi-threading was. Und zwar, dass bei einem System-Request (z.B. I/O) nur der anfragende Thread, nicht aber der gesamte Prozess blockiert wird. b) Jacketing Entwickelt als Abhilfe des Blockierungs-Problems bei ULTs. Anstatt einen blocking System Request abzusetzen, benutzt man eine Jacketing-Routine. Diese fragt via nonblocking Calls periodisch Ist Ressource frei?. Damit kann der interne ULT-Scheduler andere Threads arbeiten lassen, bis der (jetzt pseudo-blockierte) Thread von der Jacketing-Routine grnes Licht bekommt. #02 MESSAGE PASSING {02.02.2001} Zeigen Sie, dass Message-Passing und Semaphore quivalente Funktionalitt haben, indem Sie ein Semaphore mit Hilfe von Message Passing realisieren. Antwort [see Stal2001, page 246] Verwendung von 'blocking receive' und 'nonblocking send' Prozesse die auf die gleichen Resourcen zugreiffen wollen verwenden eine gemeinsame Mailbox. Diese wird zu Beginn mit einer einzelnen Nachricht initialisiert (der Inhalt dieser Nachricht ist nicht wesentlich, kann also NULL sein). Mchte ein Prozess in seinen kritischen Bereich eintreten fhrt er receive aus um eine Nachricht abzuholen. Ist die Mailbox zu diesem Zeitpunkt leer, so wird der Prozess blockierte ('blocking receive'). Hat der Prozess dann einen Nachricht erhalten, so kann er in seinen kritischen Bereich eintreten und sendet beim Verlassen dieses Bereichs die Nachricht wieder zurck an die Mailbox. Auf diese Art hat immer nur ein Prozess die Nachricht und damit ist sicher gestellt, dass stets nur ein Prozess in einem kritischen Bereich sein kann. Dabei sind noch folgende Voraussetzungen zu beachten falls mehrere Prozesse gleichzeitig ein receive ausfhren: - ist eine Nachricht vorhanden, darf nur ein einziger Prozess die Nachricht erhalten und die anderen Prozesse werden blockiert. - wenn die Mailbox leer ist, werden alle Prozess die ein receive ausfhren geblockt. Trifft dann eine Nachricht ein, wird nur ein einziger dieser Prozesse aufgeweckt und erhlt die Nachricht.

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

2 /12

#03 CRITICAL SECTION PROBLEM {02.02.2001} FRAGESTELLUNG a) Beschreiben Sie die drei notwendigen Bedingungen fr eine gltige Lsung des Critical Section Problems. b) Zeigen Sie die Korrektheit des Peterson Algos anhand dieser Bedingungen. Process Pi: repeat flag[i]:=true; turn:=j; while (flag[j] and turn =j) do {} CS flag[i]:=false; RS forever

ANTWORTEN:

a) drei notwendige Bedinugen:


Mutual exclusion es darf immer nur ein Prozess in seiner CS sein, muss fr alle Zeitpunkte sichergestellt sein Progress Nur Prozesse die gerade in ihrer Entry-Section sind, knnen in die CS Bounded Waiting Nachdem ein Prozess eine Permission Request fr seine CS abgesetzt hat, wird eine Grenze (bound) fr die anderen Prozesse festgesetzt, wie oft sie noch in die CS drfen (damit der anfragende Prozess nicht verhungert (= starvation) ).

b) Peterson Algorithmus Variablenerklrung:


Pi, Pj : Prozessnamen (P) mit Index (i bzw. j) flag[x]: Mit Flag setzt ein Prozess einen Request ab. Jeder Prozess hat sein eigenes Flag. Wenn true: ich will in CS, false: ich will nicht in CS turn: Zusatzvariable von Peterson. Laufnummer Welcher Prozess ist als nchstes dran (um Starvation zu vermeiden). CS: Critical Section, Pseudonym fr den Programmteil, wo gemeinsame Datenbereiche benutzt werden RS: Remainder Section, hier wird dem System bekannt gegeben: O.K., ich war in meiner CS und bin wieder fertig.

Allgemein: Der Peterson-Algo bezieht sich nur auf zwei Prozesse (i und j). Er kann aber leicht auf n Prozesse erweitert werden ( Bakery Algo).
Process Pi: repeat Warteschleife flag[i]:=true; turn:=j; ES while (flag[j] and turn =j) do {} CS flag[i]:=false; RS forever
3) Bounded Waiting Wird durch turn = j sichergestellt. Damit hnge ich mich in die while-Warteschleife, falls Prozess j auch schon sein Request-flag gesetzt hat.

1) Mutual Exlusion: turn kann zu jedem Zeitpunkt nur einen Wert haben (hier i oder j). Unser Prozess Pi geht nur in die CS wenn Pj nicht rein will (flag[j]=false) oder turn an uns ist (=i)

2) Progress: Prozess j kann in seine CS wenn flag[j] gesetzt ist. Also nur, wenn er in seiner Entry-Section (ES) ist. Gleiches gilt fr unseren Prozess i.

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

3 /12

THEORIE DAZU: Critical Section (CS): Kapitel 5 Sobald ein Prozess auf Shared Data (also mit anderen Prozessen geteilten Speicher) zugreift, befindet er sich in einer Critical Section (CS). So ein Zugriff muss gekapselt werden (mutual exclusiv). Der Prozess muss einen Permission Request absetzen (Erlaubnis erbitten). Diese Abfrage nennt man Entry Section. Abschlieend gibt es die Exit Section, wo der Prozess den gemeinsamen Adressraum wieder freigibt. Was der Programmteil (Code) danach macht, - auerhalb des shared Memory, nennt man Remainder Section (RS). Struktur: repeat entry section critical section exit section remainder section forever Quelle: Folien (Chapter 5: Concurrency: Mutual Exclusion and Synchronisation) Stallings, S. 212
#04 DEADLOCK {02.02.2001} a) Beschreiben Sie die vier notwendigen und hinreichenden Bedingungen fr einen Deadlock b) Stellen Sie mit Hilfe des Deadlock Detection Algos fest, ob dieses System aus Prozessen und Ressourcen zu einem Deadlock fhren kann? R1 R2 R3 R4 Available =( 2 1 0 0) P1 2 0 0 1 P2 1 0 1 0 P3 2 1 0 0 P1 0 0 1 0 Allocation = P2 2 0 0 1 P3 0 1 2 0

Claim =

Antwort [see Stal2001, page 271 and 280] (a) 4 notwendige und hinreichende Bedingungen fr einen Deadlock: 1. Mutual Exclusion - stets nur ein Prozess darf zu einem beliebigen Zeitpunkt auf eine bestimmte Resource zugreifen 2. Hold and Wait - ein Prozess hat Zugriffsrechte fr eine Resource und wartet auf die Erlaubnis auf eine weitere Resource zugreifen zu drfen 3. No Preemption - einem Prozess knnen keine von ihm gehaltene Resourcen weggenommen werden 4. Circular Wait - es existiert ein geschlossener Kreis, sodass jeder Prozess zumindest eine Resource hlt die vom nchsten Prozess im Kreis bentigt wird Die Bedingungen 1 bis 3 alleine sind notwendig, nicht aber hinreichend fr einen Deadlock. Hinreichend fr das Auftreten eines Deadlocks ist neben 1 bis 3 auch das Auftreten von 4 (bei gleichzeitigem Auftreten von 1 bis 3 bezeichnet man 4 dann als nicht mehr auflsbar). (b) Deadlock Detection 1) kein Prozess der keine Resourcen hat (keine Zeile in Allocation Matrix mit laueter 0en) -> kein Prozess markiert 2) W = Available = (2,1,0,0) 3a) P3's claim <= W -> P3 markieren W = W + (0,1,2,0) = (2,2,2,0) ... allocated resources von P3 zu W hinzuaddieren (frei sobald P3 fertig) 3b) P2's claim <= W -> P2 markieren W = W + (2,0,0,1) = (4,2,2,1) ... allocated resources von P2 zu W hinzuaddieren (frei sobald P2 fertig) 3c) P1's claim <= W -> P1 markieren W = W + (0,0,1,0) = (4,2,3,1) ... allocated resources von P1 zu W hinzuaddieren (frei sobald P1 fertig) 4) Algorithmus terminiert und alle Prozesse sind markiert => kein Deadlock!

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

4 /12

Erluterungen: Deadlock Detection Systeme machen keine Einschrnkungen beim Zugriff auf Resourcen - dieser wird gewhrt, wann immer dies mglich ist. In periodischen Abstnden versuchen solche Systeme jedoch Circular Waits zu erkennen. Available Vector ... verfgbare Systemresourcen Claim Matrix ... gibt an wieviele Resourcen eines Typs von einem bestimmten Prozess bentigt werden Allocation Matrix ... zugewiesen Systemresourcen Der Algorithmus luft so ab, dass Prozesse die in keinem Deadlock Zustand wind markiert werden. Zu Beginn sind alle Prozesse nicht markiert. 1. kennzeichne alle Prozesse die in der Claim Matrix eine Zeile mit lauter Nullen haben (besitzen keine Resourcen und sind somit sicher in keiner Deadlock) 2. initialisiere den Hilfsvektor W mit dem Inhalt der Available Vectors 3. finde einen Prozess Pi der nicht markiert ist, und dessen Claim <= W ist - markieren diesen Prozess und addiere seine schon allokierten Resourcen zu W hinzu (diese Resourcen werden nmlich verfgbar sobald der Prozess fertig ist) 4. wiederhole 3 solange bis keiner Prozess mehr gefunden wird der die Kriterien erfllt alle Prozesse die am Ende nicht markiert sind, sind in einem Deadlock Zustand Reaktionen auf gefundenen Deadlock: - alle Prozesse in Deadlock Zustand terminieren - Rollback von Prozessen in Deadlock Zustand zu vorher definiertem Checkpoint - Deadlocks nacheinander terminieren bis kein Deadlock mehr gefunden wird (mehr Resourcen frei) - Resource Preemtion - einem Prozess Resourcen wegnehmen und den anderen geben bis kein Deadlock mehr weitere Anmerkungen zum Thema Deadlock: Deadlock Prevention: Verhinderung einer der 4 Bedingungen die gemeinsam hinreichend fr Deadlock sind indirect: Verhinderung von 1, 2 oder 3 - Mutex: darf nicht verhindert werden - Hold & Wait: System einfhren, dass einem Prozess alle bentigen Resourcen simlutan zur Verfgung stellt (Prozess muss vorab bekanntgeben was er braucht - ist nicht immer vorab klar; Verzgerungen) - No Preemption: ist System statt dessen preemtive, so muss Zustand einer Resource effizient sicherbar wiederherstellbar sein direct: Verhinderung von 4 - Definition einer streng monoton wachsenden Ordnung der Resourcen O() - zu Beginn macht Prozess einen Request fr eine Anzahl von Instanzen einer Resource (Ri) - danach kann ein Prozess nur Instanzen einer Resource Rj anfordern wenn O(Rj) > O(Ri) Verhindert erfolgreich Circular Wait, ist oft aber ineffizient Deadlock Avoidance: - Resource Anforderung nicht zulassen wenn dies zu einem Deadlock fhren knnte - Aufteilung der Systemresourcen in verschiedene Klassen und Festlegung einer Ordnung fr diese Klassen - um in das System aufgenommen zu werden mssen die bentigten Resourcen einen Prozesse (vorab bekannt geben) unter dem liegen was zu diesem Zeitpunkt im System noch frei ist (unclaimed) garantiert zuverlssige Verhinderung von Deadlocks (Prozess kommt nur zu Ausfhrung wenn alle seine Bedrfnisse sicher befriedigt werden knnen); nicht optimal (geht davon aus, dass alle Prozesse ihre maximal bentigten Resourcen zum selben Zeitpunkt bekanntgeben) - Bankers Algorithmus [see Stal2001, page 276]

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

5 /12

#05 VIRTUAL MEMORY MANAGEMENT {02.02.2001} FRAGESTELLUNG Wie kann man die Strategien, den vorhandenen Hauptspeicher auf die laufenden Prozesse aufzuteilen, charakterisieren? In welche Kategorie fllt das Working-Set-Konzept? Was ist die Idee hinter diesem Konzept? Erklren Sie auch den PFF-Algo.

Begriffe: Allocation Scope

Platz (quantitativ, also wie viel), den ein Prozess im Memory bekommt Platz, aus welchem rauszuwerfende Seiten ausgesucht werden

Strategien: 1. Fixed Allocation, local Scope Festlegung wie viele Pages der Prozess bekommt bei Programmstart Bei Pagefault: Seiten des eigenen Prozesses werde rausgeworfen, um bentigte Seiten laden zu knnen Probleme: wenn gewhlte Allocation zu klein: viele PageFaults; wenn zu gro: schlechter Multi-Programming-Level. 2. Fixed Allocation, global Scope Kann nicht realisiert werden (Anz. Frames pro Prozess msste zwangslufig schwanken!) 3. Variable Allocation, global Scope (UNIX) Vorteil: leicht zu implementieren Nachteile: Prozesse knnen wuchern (unerwnscht viele Seiten in Anspruch nehmen), Auswahl bei Pagefault: Wem nehm ich eine Seite weg sehr schwer und bei weitem nicht optimal zu lsen. 4. Variable Allocation, local Scope (WinNT) Festlegung wie viele Pages der Prozess bekommt bei Programmstart, und zwar nach Typ der Anwendung Bei Pagefault Seiten des eigenen Prozesses rauswerfen um verlangte zu laden Periodische Auswertung / Evaluierung ob der Prozess zu viele od. zu wenige Pages hat! Working-Set-Konzept Fllt in Kategorie 4. Idee: Merke dir zu jedem Prozess die Pages die er stndig verwendet (= working set). Je nachdem passe seine PageAnzahl (= resident set) im Memory an. Bsp.:
Prozess-Phase START Arbeitsphase eins bergang zu Phase 2 Arbeitsphase zwei ENDE Working - Set Wchst (von 0 weg) Stabilisiert sich Wchst (z.B. auf doppelte Gre) Schrumpft wieder (da Pages von Phase 1 nicht mehr im Working Set protokolliert werden) Sowieso alle Pages killen

Working Set > free Memory: falls ein Prozess aus Sicht des Working Set nicht sinnvoll arbeiten kann (weil grad zu viele Programme dringend Speicher brauchen), wird der Prozess blockiert! (bis wieder genug Speicher frei ist) Nachteil: Protokoll fhren ist sehr aufwendig!

PFF Konzept (PageFault Frequency) Idee: Hat ein Prozess keine PageFaults, dann gehts ihm zu gut ( resident set reduzieren). Hat er zu viele PageFaults, dann kriegt er halt mehr ( resident set erhhen).

Es wird also eine upper und eine lower bound (ober- und Untergrenze) fr Pagefaults festgelegt. Beim jeweiligen berschreiten wird Speicher dazu / weggegeben.

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

6 /12

ALLGEMEIN: Ideale Prozessorauslastung hat man erreicht, wenn die Zeit zwischen den PageFaults gleich ist wie die Zeit, einen PageFault abzuarbeiten! QUELLE: Folien: Chapter 08 Virtual Memory
Anmerkung der Red. Die Frage Hauptspeicher ... hab ich mal strikt auf VM gemnzt. Kapitel 5 Memory Management beinhaltet auch noch Segmentations, ... Ich denke aber das diese Auswertung den Kern trifft, wegen Working-Set und PFF.

#06 DINING PHILOSOPHERS {20.10.2000, 12.03.1999, 08.02.1999} Kommentieren Sie folgende Lsung fr das Dining - Philosophers-Problem: Ein hungriger Philosoph nimmt zuerst seine linke Gabel. Ist die rechte Gabel ebenso frei, dann nimmt er sie und beginnt zu essen. Andernfalls legt er die linke Gabel wieder hin und beginnt von vorne. Kann Starvation/ Deadlock auftreten? Antwort [see Stal2001, page 283] Starvation: ja Begrndung: Alle Philosophen setzen sich zur selben Zeit an den Tisch und nehmen die linke Gabel auf. Wenn sie dann die rechte Gabel nehmen wolle, ist keine da und sie legen die linke Gabel wieder zurck. Nun beginnen wieder alle von vorne und nehmen wie linke Gabel auf usw. Auf diese Art findet keiner der Philosophen eine rechte Gabel vor -> Starvation. Deadlock: nein Begrndung: kein Hold and Wait - ein Philosoph der eine die linke Gabel nimmt, aber keine freie rechte Gabel vorfindet legt auch die linke wieder zurck (bei Hold & Wait wrde er die linke so lange in der Hand behalten bis auch die rechte Gabel frei ist). Damit sind sicher nicht mehr alle der 4 fr einen Deadlock notwendigen & hinreichenden Bedingungen (siehe #04) erfllt. Anmerkung: Ich bin nicht sicher ob obige Antworten korrekt sind. Mir ist nicht ganz klar wie die Abgrenzung zwischen Starvation und Deadlock erfolgt (sachdienliche Hinweise erbeten!)

#07 THREAD versus PROCESS {20.10.2000, 12.03.1999, 08.02.1999} FRAGESTELLUNG a) Beim Umschalten zwischen zwei Threads desselben Prozesses hat das BS weniger zu tun als beim Umschalten zwischen zwei Prozessen. Erklren Sie, warum dies der Fall ist. b) Ein Prozess wird beendet, whrend noch einige andere seiner Threads aktiv sind. Bleiben diese Threads aktiv? ANTWORT a) Der Prozess hlt den virtual address space und die Rechte auf Hardware. Threads eines solchen Prozesses verwenden eben diesen address-space, also den selben. Ein Kontext-Switch zwischen Threads muss also nur die Thread-spezifischen Parameter sichern / laden (wie Thread-Status, execution stack ...). Ein Prozess-Switch muss zustzlich den address space etc. sichern / laden. b) Nein. Bei Beendigung eines Prozesses wird sein address space freigegeben. Die Threads des Prozesses haben keinen eigenen space, werden daher mit terminiert. Quelle: Folien Chapter 4: Threads, SMP, Microkernels Stallings S. 156++

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

7 /12

#08 LOGISCHER ADRESSRAUM {20.10.2000, 26.05.2000, 04.07.2000, 07.02.2000, 28.05.1999, 12.03.1999, 08.02.1999} Gegeben sei ein logischer Adressraum von 32(64) pages zu je 2Kb(4Kb). Diese werden in einen physischen Adressraum von 1Mb(2Mb) gemapped. a) Wie schaut das Format der logischen Adresse aus? b) Skizzieren Sie die pagetable (Gre gesamt, Gre eines PTE) (wenn 5 bits fr diverse Status-Info bentigt werden). c) Welche Auswirkung auf die pagetable hat eine Reduktion des physischen Speichers auf 512Kb? (Vergrerung auf 4 Mb)

Antwort
(a) 2^11 = 2*1024 = 2048 ... also 11 Bit fr Codierung des Offset 2^5 = 32 ... also 5 Bit fr Codierung der Pages mit 1MB phys. Speicher und Page-Size von 2KB ... 512 Frames im Hauptspeicher 2^12 = 4*1024 = 4096 ... also 12 Bit fr Codierung des Offset 2^6 = 64 ... also 6 Bit fr Codierung der Pages mit 2MB phys. Speicher und Page-Size von 4KB ... 512 Frames im Hauptspeicher (b) PTE: P, M, control bits, Frame Number P ... present bit M ... modified bit control bis (5 Bit) frame number ... 512 Frames, coddierbar in 2^9 binr => PTE Eintrag hat somit 1 + 1 + 5 + 9 = 16 Bit da logischer Adressraum 32 bzw. 64 Pages umfasst, ist die Pagetable 32 * 16 = 512 Bit bzw. 64 * 16 = 1024 Bit gross (c) Reduktion des physikalischen Speichers von 1MB auf 512KB: mit 512KB phys. Speicher und Page-Size von 2KB ... 256 (= 2^8) Frames im Hauptspeicher PTE Grsse: 1 + 1 + 5 + 8 = 15 Bit Pagetable Gsse: 32 * 15 = 480 mit 4MB phys. Speicher und Page-Size von 4KB ... 1024 (= 2^10) Frames in Hauptspeicher PTE Grsse: 1 + 1 + 5 + 10 = 17 Bit Pagetable Grsse: 64 * 17 = 1088

#09 DISK SCHEDULING VERFAHREN

STOFF (?)

{20.10.2000, 26.05.2000, 07.04.2000} Bei welchen der Disk-Schedulingverfahren FCFS, SSTF und SCAN kann Verhungern der Prozesse auftreten? Wie kann man das verhindern? Theorie dazu: Sinn & Zweck: Wie behandle ich Disk-I/O Requests. FCFS: First Come First Served = FIFO SSTF: Shortest Service Time First SCAN: Tastkopf immer nur in eine Richtung (ab Anschlag Richtung umdrehen) FIFO: First In First Out Round Robin SRT: Shortest Remaining Time

ANTWORT Der SSTF-Algorithmus schliet ein Verhungern einer Anfrage nicht aus. Verhindern: indem man den Tastkopf nicht links/rechts zum Nchsten Datensegment, sondern in eine Richtung bis Anschlag, danach retour ( SCAN Algo.!).

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

8 /12

#11 SCHEDULING {26.05.2000, 07.04.2000} Stellen Sie sich vor, ein Scheduling Verfahren (im Bereich des short-term CPU Scheduling) bevorzuge diejenigen Prozesse, welche in der unmittelbaren Vergangenheit die wenigste CPU-Zeit verbraucht haben. Wird dieses Verfahren I/O orientierte oder CPU-orientierte Prozesse bevorzugen? Knnen bei diesem Verfahren I/O orientierte oder CPU-orientierte Prozesse verhungern? Begrnden Sie ihre Antwort. Antwort [see Stal2001, page 398] Anm.: hab (noch) keinen Stal2001 - also alles nur IMHO ;) Da I/O orientierte Prozesse eher weniger CPU-Zeit bentigen (I/O orientierte Prozesse befinden sich hufig im blocking state wenn auf einen I/O request gewartet wird) werden diese von solch einem Scheduler bevorzugt. Befinden sich viele I/O-lastige Prozesse im System so kann es durchaus vorkommen, das CPU-orientierte Prozesse verhungern. z.B. folgendes Szenario: es sind so viele I/O-lastige Prozesse gestartet, sodass sich immer zumindest ein solcher Prozess in der ReadyQueue befindet (whrend die anderen z.B. gerade auf ein Event warten) so werden diese vom Scheduler bevorzugt, da diese ja wenig CPU-Zeit bentigen. In solch einem Fall knnte es vorkommen, das CPU-orientierte Prozesse verhungern

#12 VERKEHRS DEADLOCK {26.05.2000, 07.04.2000} Betrachten Sie den Verkehrs-Deadlock in der folgenden Abb. Zeigen Sie, dass die vier notwendigen Voraussetzungen fr einen Deadlock erfllt sind. Welche Deadlock Verhinderungsverfahren sind anwendbar? Wie? Welche Verkehrsregel sollte derartige Deadlocks verhindern? Antwort [see Stal2001, page ] Anmerkung: Zeichnung fehlt bei den beiden Prfungsterminen - Vermutung: es handelt sich um das Traffic-Problem aus [Stal2001] auf Seite 266

B D C

Abb. 1 - ungeregelte Kreuzung

Abb. 2 - Deadlock

4 Autos (A, B, C, D) kommen auf eine ungeregelte Kreuzbg zu, und wollen alle gerade aus weiter fahren. Die 4 Quadranten 1, 2, 3, 4 der Kreuzbg sind entsprechen den Resourcen die die Autos bentigen. Fahren nun alle 4 Autos in die Kreuzubg ein und beanspruchen den ersten auf ihrem Weg gelegenen Quadranten, so kommt es zum Deadlock (Abb 2). 1. Mutual Exclusion - es darf/kann nur immer jeweisl ein Auto eine bestimmte Resource (einer der 4 Quadranten fr sich beanspruchen). 2. Hold and Wait - in Abb2 sind alle 4 Autos in die Kreuzung eingefahren und jeder wartet darauf, dass der Quadrant der ihm das passieren der Kreuzung ermglichen wrde von seinem Gegenber freigegeben wird. Keiner der Fahre gibt aber seinen Quadranten auf - jeder hlt also seinen besetzten Quadranten und wartet. 3. No Preemtion - keinem der 4 Autos kann der von ihm besetzte Quadrant weggenommen werden (Abschleppwagen?) 4. Circular Wait - es existiert ein geschlossener Kreis, sodass jedes einen Quadranten besetzt hlt, den das nchste Auto zum Passieren dier Kreuzung bentigt alle 4 Bedingungen erfllt => Deadlock!

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

9 /12

Deadlock Verhinderung (Prevention): Deadlock Prevention versucht eine der 4 notwendigen/hinreichenden Bedingungen fr einen Deadlock zu verhindern. 1. Mutex - nicht sinnvoll verhinderbar 2. Hold & Wait - Verhinderung mglich (siehe unten: Verhinderung durch Verkehrsregel) 3. No Preemtion - Entfernung eines Autos von aussen (Abschleppwagen? s.o.) 4. Ordnung fr die 4 Quadranten festlegen (?) Verhinderung durch Verkehrsregel: Die StVO sieht afaik fr so einen Fall vor, dass einer der 4 Autofahrer nachzugeben hat und das z.B. durch Handzeichen den anderen Autofahrern mitteilt. Auf Computer bertragen wre z.B. denkbar eine Regel (Abfrage) z.B. fr das Auto auf Position 1 einzufhren die die anderen 3 Quadranten prft. Befinden sich auch dort Fahrzeuge, so gibt das Fahrzeug an Posotion 1 seine Platz frei und setzt zurck (Hold & Wait aufgehoben). Anmerkung: Die Fragestellung in diesem Beispiel erscheint mir etwas eigenartig/unklar. Dementsprechend unsicher sind auch meine Antwortversuche (Kritik/Verbesserungen jederzeit willkommen!) #13 FRISR {26.05.2000, 07.04.2000, 07.02.2000} Der schlafende Frisr: ein Frisrladen besteht aus einem Warteraum mit n-Sthlen und der Frisierstube mit dem Frisiersessel. Wenn keine Kunden da sind, geht der Frisr schlafen. Betritt ein Kunde den Laden und es sind alle Sthle besetzt, dann geht der Kunde wieder. Sind Sesses frei, und der Frisr ist beschftigt, dann wartet der Kunde in einem der freien Sessel. Wenn der Frisr schlft, so weckt ihn der Kunde wieder auf. Schreiben Sie ein Programm (Pseudoprogrammiersprache) dass die Kunden und den Frisr koordiniert. Sie drfen Semaphore und/oder Monitore verwenden. Antwort [see Stal2001, page 229] frisr: repeat work() forever client: repeat goForAHairCut until MyHairAreNice Monitor: Initialisierung customerHere: chair: hairAreNice: waitingRoom: count count count count = = = = 0 1 0 1 // // // // Niemand am Anfang am Sessel Einer kann auf den Sessel Niemand hat noch schne Haare Immer nur einer darf die Anzahl der Sitze verndern das ist eigentlich nur ein Lock auf waitingCustomers // Niemand wartet (ist eigentlich eine Info-Verdoppelung, in |chair.count| steht die selbe Zahl. Normalerweise ist count aber private)

// Funktion des Monitors

// Funktion des Monitors // sollte goForAHairCut returnieren ohne, dass man dann eine feschen Haarschnitt hat, war der Wartesaal voll

waitingCustomers = 0

procdure work begin // 1. Warten auf einen zu verunstaltenden wait(customerHere) // 2. Typ sitzt am Sessel, loslegen cutHair // 3. "Du bist fertig, abmarsch" signal(hairAreNice) // 4. "Der Nchste, bitte!" signal(chair) end

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

10 /12

procedure goForAHairCut begin // 1. Jeder mu schauen ob er prinzipiell Platz htte im Warteraum wait(waitingRoom) if waintingCustomers >= chairsInWaitingRoom signal(waitingRoom) exit else waitingCustomers++ signal(waitingRoom) // 2. Ich habe Platz, jetzt warte ich, dass ich beim Frisr drankomm wait(chair) // 3. Der Frisr hat mich hereingebeten, ich sag ihm er kann anfangen waitingCustomers-signal(customerHere) // 4. Warten bis ich hbsch gemacht worden bin wait(hairAreNice) end

#14 ROUND ROBIN {07.02.2000} Stellen Sie sich folgende Variante des Round-Robin Verfahrens vor (bei dem in der Queue Pointer auf die PCB?s stehen): es werden zwei Pointer auf denselben Prozess in die Ready Queue gestellt. Was htte dies fr Auswirkungen? Was wren die wichtigsten Vor- und Nachteile? Knnten Sie denselben Effekt auch anders erreichen? Antwort [see Stal2001, page 115] Round Robin: Jeder Prozess in der Queue bekommt einen bestimmte Zeit fr seine Ausfhrung und wird dann wieder, sofern er nicht blockiert wurde (blocking Syscall oder hnliches), wieder in die Ready-Queue eingereiht (aka time slicing anhand von timer interrupt). Sind nun 2 Pointer auf ein und den selben PCB (Process Control Block) vorhanden so bedeutet das, dass der fragliche Prozess in etwa doppelt so oft in den Running Zustand kommen wie sonst (exakte Aussage ist hier nicht mglicher weil z.B. nicht bekannt ist, wie IO lastig der Prozess ist - d.h. wie hufig er auf grund von SysCalls oder hnlichem in den in den Blocking Zustand kommt). Vorteile: Prozess erhlt mehr Rechenzeit Nachteile: Inkohrenzen mssen explizit abgefangen werden! Beispiel: Prozesse: X, Y, Z mit Pointern PX, PY, PZ1 und PZ2 (Z hat zwei Pointer!) READY-Queue: [PZ1, PX, PZ2] Sceduler whlt PZ1 Z wird ausgefhrt, macht einen blocking-SysCall und PZ1 wird in BLOCKED-Queue verschoben Jetzt steht PZ1 in BLOCKED, und PZ2 in READY-Queue !!! Andere (und saubere) Mglichkeit um den selben Effekt zu erzielen: Verwendung eines Scheduling Verfahrens das mit Prioritten arbeiten. Man knnte dem Prozess dann eine doppelt so hohe Prioritt geben wie allen anderen Prozessen

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1

Vortragender: Udo Payer

11 /12

#15 SCHEDULING {07.02.2000, 28.05.1999} a) Erklren Sie den Unterschied zwischen preempive und non - preemptive scheduling. b) Diskutieren Sie den Grad der Bevorzugung kurzer Prozesse bei den Scheduling Verfahren FirstComeFirstServed, RoundRobin und MultilevelFeedbackQueues.

Antwort
a) non-preemptive: Ein Prozess der an der Reihe ist (running) wird nicht unterbrochen, bis er entweder fertig ist (running-> finsihed), oder einen I/O-Request absetzt (running -> blocked). preemptive: Es gibt auch vom OS aufgezwungene Unterbrechungen (bergang running -> ready) Kommt nur vor wenn das OS (der Scheduler) irgendwie zum Zug kommt (Interrupt, zb Timer) b) Theorie: "Kurzer Prozess": ein Prozess der nicht viel von der ihm zugewiesenen CPU-Zeit verwenden kann, weil er I/O lastig ist und immer recht schnell geblockt wird. FCFS: Immer einfach den nchsten aus der ready-Queue (non-preemptive) (FIFO) RoundRobin: wie FCFS aber preemtive; jeder bekommt eine Zeitscheibe -> wird nach Ablauf der Zeitscheibe zurckgestellt in ready, wenn er nicht vorher schon einen I/O-Request absetzt und blocked wird. MultilevelFeedbackQueues: jeder startende prozess bekommt eine bestimmte Zeitscheibe und kommt in die erste Queue. es wird immer gemessen wie lange es Prozess dran bleibt: Zeit der CPU-Ntzung bis zum I/O-Request. Wenn diese Dauer ein Limit berschreitet, kommt er in eine tiefere Queue. Hhere Queues werden bei der Auswahl des nchsten Prozesses der dran kommt bevorzugt. Innerhalb einer Queue gilt FIFO, nur in der untersten Round-Robin. Kurze Prozesse (I/O lastige) berschreiten weniger Zeitlimits und bleiben dadruch in hheren Queues. Vergleich: Kurze Prozesse werden benachteiligt, weil sie gleich oft drankommen wie lange, aber immer nur recht kurz arbeiten knnen. RoundRobin: Benachteiligung wirkt sich geringer aus, weil auch lange Prozesse immer wieder unterbrochen werden und die von kurzen Prozessen ungentzte Zeit ist nicht mehr so gro (hngt von der Dauer der Zeitscheiben ab) -> weitere Verbesserung "virtual Round Robin": Prozesse die Blocked waren kommen nicht in ready-queue zurck, sondern in eine auxiliary-queue die der ready-queue vorgezogen wird und bekommen die chance, den rest ihrer zeitscheibe aufzubrauchen MultilevelFeedbackQueues: Kurze Prozesse werden bevorzugt. Das kann so weit gehen, dass man mit langen Prozessen ein Starvation-Problem hat. Auerdem werden sie stark in die lnge gezogen -> Lsungsansatz: Prozesse in tieferen queues bekommen etwas lngere Zeitscheiben. FCFS:

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM

Betriebssysteme 1 #18 SEMAPHORE

Vortragender: Udo Payer

12 /12

{05.07.1999} Sempahore: Zeigen Sie, dass Mutex nicht garantiert wird, wenn die Operationen wait() und signal() nicht atomar sind? Antwort: Definitionen wait() { count--; if (count < 0) Sleep(); } signal() { count++; if (count <= 0) WakeOneThreadAndPutOnReadyQueue }

Ablauf: 1.) Prozess 1 hngt im wait 2.) Prozess 2 ruft signal auf und kommt bis zu count++ 3.) Prozess 3 ruft wait auf bevor der Prozess 1 zum laufen kommt -> jetzt kommt Prozess 3 ber das "if (count < 0)" drber und in die CS whrend Prozess 1 sie noch nicht verlassen hat. kein Mutex

#19 PAGING-ALGO / USED BIT {05.07.1999} Angenommen wir wollen einen paging - Algo implementieren, der ein used bit verwendet, jedoch stellt die Hardware dieses nicht zur Verfhrung. Skizzieren Sie, wie man dieses bit simulieren knnte - oder erklren Sie warum dies nicht mglich ist. Falls es mglich ist, schtzen Sie noch den Mehraufwand ab. Antwort 1: Hardware mit TLB: Das Used-Bit wird (wenn in HW vorhanden) direkt von der MACHINE gesetzt. Dies geschieht bei jedem read / write Zugriff auf die Page. Der Zugriff ist fr unseren Kernel nicht greifbar, es sei denn er scheitert (PageFaultException). NICHT SIMULIERBAR Hardware ohne TLB, Zugriff ber PageTable:

Jeder read / write Zugriff auf den Speicher passiert ber den AddressSpace des aktuellen Prozesses. Damit kann der Kernel eine Used-Liste mitfhren (Array mit length = length (PageTable), boolean). SIMULIERBAR Mehraufwand:
1 Befehl mehr pro Zugriff (extra Setzen des Used-Bit): halbiert effektive Rechnerleistung!; Speed-Up durch schlaueres MemManagement wohl kaum gro genug, um das wieder aufzuholen! eine Liste mehr im AddressSpace (Mehraufwand minimal). Antwort 2: (auf die wir uns bei Vorbereitung geeinigt haben!) GENERELL NICHT SIMULIERBAR ... weil wenn die Machine zugreift und kein Bit in HW setzt, dann knn ma des a net wissen !

- END -

Fragenausarbeitungen ohne Disc-Sceduling Verfahren

Feb. 2002

TOM-MIKE-PAUL-QUAM