Fixes from review

ws22.q

@@ -166,11 +166,11 @@
 
 0 Welche Aussage zum Thema Adressraumverwaltung ist richtig? (Februar 2022)
 + Ein Speicherbereich, der mit Hilfe der Funktion free() freigegeben wurde, verbleibt im logischen Adressraum des zugehörigen Prozesses.
-  Ja. Der **logische** Adressraum Aₗ = [n, m] ist der gesamte Adressbereich ohne Lücken, der einem Prozess zugeordnet wird. Dieser wird im allgemeinen nicht verkleinert, wenn `free` aufgerufen wird. Im Gegensatz dazu ist der virtuelle Adressraum Aᵥ jener, der nur partiell auf den Hauptspeicher abgebildet wird, bei dem also Adressen ungültig sein können. (vgl. SP1 B Vl. 2 S. 12 ff., 27) (Bin mir hier nicht zu 100 % sicher, dass meine Interpretation korrekt ist)
+  Ja. Der **logische** Adressraum Aₗ = [n, m] ist der gesamte Adressbereich ohne Lücken, der einem Prozess zugeordnet wird. Dieser wird nicht verkleinert, wenn `free` aufgerufen wird. Im Gegensatz dazu ist der virtuelle Adressraum Aᵥ jener, der nur partiell auf den Hauptspeicher abgebildet wird, bei dem also Adressen ungültig sein können. (vgl. SP1 B Vl. 2 S. 12 ff., 27) (Bin mir hier nicht zu 100 % sicher, dass meine Interpretation korrekt ist)
 - Mit malloc() angeforderter Speicher, welcher vor Programmende nicht freigegeben wurde, kann vom Betriebssystem nicht mehr an andere Prozesse herausgegeben werden und ist damit bis zum Neustart des Systems verloren.
-  Nein, nach dem Ende des Programms wird der gesamte Adressbereich des Prozesses freigegeben.
+  Nein, nach dem Ende des Programms wird der gesamte Adressbereich des Prozesses freigegeben. Das ist möglich, weil das Betriebsystem den Speicher für jeden Prozess virtualisiert und damit auch in der Lage ist, ihm diese Ressource zu entziehen.
 - Mit Hilfe des Systemaufrufes malloc() kann ein Programm zusätzliche Speicherblöcke von sehr feinkörniger Struktur vom Betriebssystem anfordern.
-  Nein, die Laufzeitumgebung (*libc*) fordert den Speicher grobgranular vom Betriebssystem an (`mmap(2), brk(2)`) und verteilt diesen im Benutzerprozess. Zudem ist `malloc(3)` kein Systemaufruf, sondern eine Bibliotheksfunktion, die im *userspace* implementiert ist und die zuvor genannten Systemaufrufe verwendet.
+  Nein, `malloc(3)` ist kein Systemaufruf, sondern eine Bibliotheksfunktion. Außerdem fordert die Laufzeitumgebung (*libc*) den Speicher üblicherweise grobgranular vom Betriebssystem an (`mmap(2), brk(2)`) und verteilt diesen im Benutzerprozess.
 - Da das Laufzeitsystem auf die Betriebssystemschnittstelle zur Speicherverwaltung zurückgreift, ist die Granularität der von malloc() zurückgegebenen Speicherblöcke vom Betriebssystem vorgegeben.
   Nein, `malloc` kann als Teil des Laufzeitsystems den grobgranular vom Betriebssystem angeforderten Speicher feingranular aufteilen und zurückgeben.
 .
@@ -190,7 +190,7 @@
 - Schwergewichtige Prozesse sind die einzige Klasse von Prozessen, die auf einem Multiprozessorsystem echt parallel ausgeführt werden kann, da nur hier jeder Benutzerfaden einem eigenen Kernfaden zugeordnet ist.
   Nein. Auch leichtgewichtigen Prozessen (*kernel-level threads*) ist ein *kernel thread* zugeordnet.
 + Federgewichtige Prozesse (*user-level threads*) blockieren sich bei blockierenden Systemaufrufen gegenseitig.
-  Ja, da bei federgewichtigen Prozessen mehrere Prozesse auf einen *kernel-level thread* gemultiplext werden, wird die Ausführung der aller federgewichtigen Prozesse blockiert, die auf einem *kernel-level thread* ausgeführt werden, bis dieser wieder bereit ist.
+  Ja, da bei federgewichtigen Prozessen mehrere Prozesse auf einen Systemkernfaden (*kernel-level thread*) gemultiplext werden, wird die Ausführung der aller federgewichtigen Prozesse blockiert, die auf einem *kernel-level thread* ausgeführt werden, bis dieser wieder bereit ist.
 - Beim Blockieren eines schwergewichtigen Prozesses werden alle anderen schwergewichtigen Prozesse, die das selbe Progamm ausführen, ebenfalls blockiert.
   Nein. Man kann mehrere Prozesse mit dem gleichen Programm ausführen.
 - Zu jedem leichtgewichtigen Prozess (*kernel-level thread*) gehört ein eigener, isolierter Adressraum.
@@ -201,20 +201,20 @@
 + Im Seitendeskriptor wird ein spezielles Bit geführt, das der MMU zeigt, ob eine Seite eingelagert ist oder nicht. Falls die Seite nicht eingelagert ist, löst die MMU einen Trap aus.
   Ja, die *page descriptor table* enthält für jeden Seitendeskriptor ein *valid*-Bit. Ist dieses nicht gesetzt, so wird ein *Trap* ausgelöst.
 - Im Seitendeskriptor steht bei ausgelagerten Seiten eine Adresse des Hintergrundspeichers und der Speichercontroller leitet den Zugriff auf den Hintergrundspeicher um.
-  Nein, die MMU interagiert nicht mit dem Hintergrundspeicher.
+  Nein, die MMU interagiert nicht mit dem Hintergrundspeicher, sondern ist nur für die Adressabbildung von logischen zu realen Adressen zuständig.
 - Das Betriebssystem erkennt die ungültige Adresse vor Ausführung des Maschinenbefehls und lagert die Seite zuerst ein bevor ein Trap passiert.
-  Nein, das Betriebssystem überprüft nicht jede Instruktion vor der Ausführung. (vgl. **Teil**interpretation)
+  Nein, das Betriebssystem überprüft nicht jede Instruktion vor der Ausführung (vgl. **Teil**interpretation).
 - Bei Programmen, die in virtuellen Adressräumen ausgeführt werden sollen, erzeugt der Compiler speziellen Code, der vor Betreten einer Seite die Anwesenheit überprüft und ggf. die Einlagerung veranlasst.
-  Nein, der Compiler fügt nicht in jedes Programm eine Implementation der Speicherverwaltung ein.
+  Nein, der Compiler fügt nicht in jedes Programm eine Implementation der Speichervirtualisierung ein. Diese ist eine Aufgabe des Betriebssystems und nicht der einzelnen Benutzerprogramme.
 .
 
 0 Welche der folgenden Aussagen zum Thema Seitenfehler (*Page Fault*) ist richtig? (Februar 2022)
 - Wenn der gleiche Seitenrahmen in zwei verschiedenen Seitendeskriptoren eingetragen wird, löst dies einen Seitenfehler aus (Gefahr von Zugriffskonflikten!).
   Nein, das würde z. B. zwischen Prozessen geteilten Speicher verhindern.
 - Ein Seitenfehler wird ausgelöst, wenn der Offset in einer logischen Adresse größer als die Länge der Seite ist.
-  Nein, dieser Fall kann per Definition nicht eintreten. Seiten haben eine Größe von 2ⁿ Byte, (bei x86-64 z. B. 4 KiB), n Byte der Adresse werden als Offset interpretiert. Somit ist dieser Fall außerhalb des überhaupt darstellbaren Wertebereichs für den Offset.
+  Nein, dieser Fall kann per Definition nicht eintreten. Seiten haben eine Größe von 2ⁿ Byte, (bei x86-64 z. B. 4 KiB), n Byte der Adresse werden als Offset interpretiert. Somit ist dieser Fall außerhalb des überhaupt darstellbaren Wertebereichs für den Offset. Im Gegensatz dazu wird bei Segmentierung überprüft, ob die logische Adresse im Speichersegment liegt, das dem Prozess zugeordnet ist. Dort könnte also ein derartiger Fehler auftreten.
 - Ein Seitenfehler zieht eine Ausnahmebehandlung nach sich. Diese wird dadurch ausgelöst, dass die MMU das Signal SIGSEGV an den aktuell laufenden Prozess schickt.
-  Nein, ein Seitenfehler kann auch dadurch ausgelöst werden, dass z. B. auf eine ausgelagerte Seite zugegriffen wird. Diese wird dann für den Prozess transparent eingelagert.
+  Nein, ein Seitenfehler kann auch dadurch ausgelöst werden, dass z. B. auf eine ausgelagerte Seite zugegriffen wird. Diese wird dann für den Prozess transparent eingelagert. Zudem löst die MMU ein Trap aus, welches später zur Zustellung eines Signals führen kann. Jedoch schickt sie nicht selbst Signale an Prozesse.
 + Das Auftreten eines Seitenfehlers kann dazu führen, dass der aktuell laufende Prozess in den Zustand beendet überführt wird.
-  Ja, wenn der Prozess auf eine ungültige Adresse zugreift, also insbesondere auch keine Seite eingelagert werden kann und das entsprechende Signal nicht abgefangen wird, kann er terminiert werden.
+  Ja, wenn der Prozess auf eine ungültige Adresse zugreift, also insbesondere auch keine Seite eingelagert werden kann und das entsprechende Signal nicht abgefangen wird, wird er terminiert.
 .