From ab9484b343abd995cba915bb0ba4be8907dfa6ec Mon Sep 17 00:00:00 2001 From: Gregor Kleen Date: Fri, 13 Nov 2015 23:45:26 +0000 Subject: Shorter lecture names --- ws2015/betriebssysteme/blaetter/01/abgabe.md | 27 -------------------- ws2015/betriebssysteme/blaetter/02/abgabe.md | 21 --------------- ws2015/betriebssysteme/blaetter/03/abgabe.md | 13 ---------- ws2015/betriebssysteme/blaetter/04/abgabe.md | 38 ---------------------------- 4 files changed, 99 deletions(-) delete mode 100644 ws2015/betriebssysteme/blaetter/01/abgabe.md delete mode 100644 ws2015/betriebssysteme/blaetter/02/abgabe.md delete mode 100644 ws2015/betriebssysteme/blaetter/03/abgabe.md delete mode 100644 ws2015/betriebssysteme/blaetter/04/abgabe.md (limited to 'ws2015/betriebssysteme') diff --git a/ws2015/betriebssysteme/blaetter/01/abgabe.md b/ws2015/betriebssysteme/blaetter/01/abgabe.md deleted file mode 100644 index 405ab62..0000000 --- a/ws2015/betriebssysteme/blaetter/01/abgabe.md +++ /dev/null @@ -1,27 +0,0 @@ -# Aufgabe 4 -- Realisierung von Unterprogrammen - -a) - - Code duplication -- Etwaige spätere Änderungen müssen manuell an alle Stellen kopiert werden. - - Argumente müssen manuell an jede Stelle eingepflegt werden. -b) Die Kosten der Befehle für das Springen ins Unterprogramm und das kopieren der Argumente/Return-Values können groß sein gegen die Kosten des Unterprogramms. -c) - - Die Parameter können auf den Stack gepusht werden, bevor in das Unterprogramm gesprungen wird. - - Manche Maschinen bieten spezielle Register für diesen Zweck. -d) Während der Ausführung unterhält die Maschine ein Register, das die Adresse des nächsten auszuführenden Befehls enthält. - Diese kann beliebig überschrieben werden. -e) - `JMP` - ~ überschreibt nur das Adress-Register. - - `CALL` - ~ speichert vor dem Überschreiben des Adressregisters noch eine Adresse an die, nach Ausführung des Unterprogramms, in das gesprungen wird, zurückgesprungen werden soll. -f) `RET` muss so implementiert werden, dass es die Rücksprungadresse aus dem selben Register zu lesen versucht, in das `CALL` sie speichert. - `CALL` speichert die Adresse entweder in einem speziellen Register oder auf dem Stack. - -# Aufgabe 5 -- Das Betriebssystem - -a) $2^n \cdot m~\text{Byte}$ -b) Maschinensprache -c) Textverabeitung -d) Gerätetreiber -e) offene diff --git a/ws2015/betriebssysteme/blaetter/02/abgabe.md b/ws2015/betriebssysteme/blaetter/02/abgabe.md deleted file mode 100644 index adf72ce..0000000 --- a/ws2015/betriebssysteme/blaetter/02/abgabe.md +++ /dev/null @@ -1,21 +0,0 @@ -# Aufgabe 9 -- Multiprogramming - -a) - Unter Multiprogramming versteht man die Praxis den Prozessor der Maschine mit - hoher Frequenz zwischen mehreren auszuführenden Prozessen hin- und herschalten - zu lassen. -b) - Die Resourcennutzung kann im Normalfall (viele jeweils wenig CPU-Intensive - Prozesse) verbessert werden. -c) - Prozesse können echt parallel ausgeführt werden (im Idealfall wird also die - CPU-Leistung vervielfacht), es ist jedoch komplexes Scheduling erforderlich - und Kontextwechsel kann teuer sein. - -# Aufgabe 10 -- Programme und Unterprogramme - -a) Systemaufrufe (Syscalls) -b) rekursiv -c) Endadresse des Unterprogramms -d) (iii) -e) Clientanwendung diff --git a/ws2015/betriebssysteme/blaetter/03/abgabe.md b/ws2015/betriebssysteme/blaetter/03/abgabe.md deleted file mode 100644 index 3e6b599..0000000 --- a/ws2015/betriebssysteme/blaetter/03/abgabe.md +++ /dev/null @@ -1,13 +0,0 @@ -# E/A-Operationen mit Hilfe von Interrupts - -a) Interrupts sind Befehle an die CPU, die einen Sprung in den entsprechenden Handler des Betriebssystems verursachen und von externen Quellen ausgelöst werden (Uhr, E/A Peripherie, …) -b) Alternativ zu Interrupt-basiertem E/A könnten Geräte auch ihren aktuellen Status auf eine Abfrage des aktuellen Prozesses hin zur verfügung stellen. -c) Aktives Polling würde effektiv Prozesszyklen verschwenden jedoch den Prozessfluss deterministischer gestalten. - -# Einführung in Betriebssysteme - -a) Statusbus -b) `(0,0,0,0)` -c) PC (Program Counter) -d) Das Nutzerprogramm bleibt blockiert, bis die E/A-Operation abgeschlossen ist. -e) `div $t0,$t1,$t2` diff --git a/ws2015/betriebssysteme/blaetter/04/abgabe.md b/ws2015/betriebssysteme/blaetter/04/abgabe.md deleted file mode 100644 index 94578c5..0000000 --- a/ws2015/betriebssysteme/blaetter/04/abgabe.md +++ /dev/null @@ -1,38 +0,0 @@ -# 5-Zustands-Prozessmodell - -a) - i) Übergang von *blocked* zu *running* wird nur via *ready* realisiert, da der Scheduler bereits periodisch Prozesse aus *ready* aufweckt. - Zusätzlich auch noch den jeweiligen Prozess aufzuwecken wäre schlicht unnötig. - ii) Fordert ein Prozess E/A-Resourcen an, so wird er nach *blocked* verschoben bis die jeweilige E/A-Operation per Unterbrechung bekannt macht, dass der Vorgang abgeschlossen ist. - iii) Ein Prozess, der nicht läuft, kann keine E/A-Resource anfordern. -b) - (i) *new* → *ready* - ~ Ein Nutzer hat seine Shell angewiesen `Hello World!` auszugeben, diese forkt um später `/bin/echo` aufzurufen. - - *ready* → *running* - ~ Der Shell-Prozess ruft `wait` auf den soeben gespawnten Prozess auf und wird daher *blocked*. - Der Scheduler entscheidet nun zum Kindprozess zu wechseln. - - *running* → *ready* - ~ `/bin/echo` hat nicht innerhalb der switching-Frequenz des Schedulers terminiert. - Der Scheduler verschiebt `/bin/echo` in *ready* und wechselt zu einem anderen Prozess. - - *running* → *blocked* - ~ `/bin/echo` ist dynamisch gelinkt und möchte eine library von der Festplatte lesen. - Es setzt einen Syscall ab und wartet auf das Ergebnis. - - *blocked* → *ready* - ~ Die Festplatte fängt an einen Stream von bytes zu schicken. - Der Scheduler fängt die Unterbrechung ab und verschiebt `/bin/echo` nach *ready* - - *running* → *exit* - ~ `/bin/echo` terminiert. - (ii) *new*. Prozesse werden im reinen batch-betrieb nicht dynamisch erzeugt. - -# Prozesse - -a) Kontext -b) Uniprogramming -c) 13.3 min -d) `fork` -e) Scheduler -- cgit v1.2.3