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/oss/blaetter/01/abgabe.md | 27 +++++++++++++++++++++++++++ ws2015/oss/blaetter/02/abgabe.md | 21 +++++++++++++++++++++ ws2015/oss/blaetter/03/abgabe.md | 13 +++++++++++++ ws2015/oss/blaetter/04/abgabe.md | 38 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 99 insertions(+) create mode 100644 ws2015/oss/blaetter/01/abgabe.md create mode 100644 ws2015/oss/blaetter/02/abgabe.md create mode 100644 ws2015/oss/blaetter/03/abgabe.md create mode 100644 ws2015/oss/blaetter/04/abgabe.md (limited to 'ws2015/oss') diff --git a/ws2015/oss/blaetter/01/abgabe.md b/ws2015/oss/blaetter/01/abgabe.md new file mode 100644 index 0000000..405ab62 --- /dev/null +++ b/ws2015/oss/blaetter/01/abgabe.md @@ -0,0 +1,27 @@ +# 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/oss/blaetter/02/abgabe.md b/ws2015/oss/blaetter/02/abgabe.md new file mode 100644 index 0000000..adf72ce --- /dev/null +++ b/ws2015/oss/blaetter/02/abgabe.md @@ -0,0 +1,21 @@ +# 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/oss/blaetter/03/abgabe.md b/ws2015/oss/blaetter/03/abgabe.md new file mode 100644 index 0000000..3e6b599 --- /dev/null +++ b/ws2015/oss/blaetter/03/abgabe.md @@ -0,0 +1,13 @@ +# 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/oss/blaetter/04/abgabe.md b/ws2015/oss/blaetter/04/abgabe.md new file mode 100644 index 0000000..94578c5 --- /dev/null +++ b/ws2015/oss/blaetter/04/abgabe.md @@ -0,0 +1,38 @@ +# 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