Add more questions

ws22.q

@@ -77,7 +77,7 @@
   Nein, bspw. wenn man versucht auf nicht lesbaren Speicher versucht
   zuzugreifen, muss es abgebrochen werden, bevor auf den Speicher
   zuggegriffen wurde.
-  
+
 + Die CPU sichert bei einem Interrupt einen Teil des Prozessorzustands.
 
   Ja, genau wie bei einer Signal-Behandlung unterbricht ein Interrupt
@@ -95,7 +95,7 @@
   Nebenläufigkeit welche Probleme bereitet.
 
 ? Wenn ein Interrupt ein schwerwiegendes Ereignis signalisiert, wird das unterbrochene Programm im Rahmen der Interruptbearbeitung immer abgebrochen.
-    
+
 - Ein Systemaufruf im Anwendungsprogramm ist der Kategorie Interrupt zuzuordnen.
 
   Nein, weil diese deterministisch immer dann auftreten, wenn ein Programm ein Systemaufruf absetzen will.
@@ -163,3 +163,58 @@
 - Die Position der Seite im virtuellen Adressraum.
   Nein, diese Zuordnung findet nicht im Seitendeskriptor statt, sondern im Betriebsystem.
 .
+
+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)
+- 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.
+- 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.
+- 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 zurückgeben.
+.
+
+0 Sie kennen den Translation-Lookaside-Buffer (TLB). Welche Aussage ist richtig? (Februar 2022)
+- Der TLB puffert die Ergebnisse der Abbildung von physikalische auf logische Adressen, sodass eine erneute Anfrage sofort beantwortet werden kann.
+  Nein, andersherum. Logische müssen in physikalische Adressen übersetzt werden.
++ Verändert sich die Speicherabbildung von logischen auf physikalische Addressen aufgrund einer Adressraumumschaltung, so werden auch die Daten im TLB ungültig.
+  Ja, da die Einträge im TLB beziehen sich auf einen bestimmten logischen Adressraum.
+- Wird eine Speicherabbildung im TLB nicht gefunden, wird vom Prozessor immer eine Ausnahme (*Trap*) ausgelöst die vom Betriebssystem behandelt wird.
+  Nein, ist kein Eintrag im TLB zu finden, wird die Addresse von der MMU aufgelöst. PS: Die Verwendung von *Trap* wäre hier im Gegensatz zu *Interrupt* korrekt.
+- Wird eine Speicherabbildung im TLB nicht gefunden, wird der auf den Speicher zugreifende Prozess mit einer Schutzraumverletzung (Segmentation Fault) abgebrochen.
+  Nein, ist kein Eintrag im TLB zu finden, wird die Addresse von der MMU aufgelöst. Der TLB agiert nur als *cache* für Adressübersetzungen.
+.
+
+0 Welche Aussage zu den verschiedenen Gewichtsklassen von Prozessen trifft zu? (Februar 2022)
+- 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.
+- 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.
+  Falsch, das wären schwergewichtige Prozesse. Leichtgewichtige Prozesse wie `pthread`s teilen sich einen Adressraum.
+.
+
+0 Wie wird erkannt, dass eine Seite eines virtuellen Adressraums, auf die ein Maschinenbefehl zugreift, gerade ausgelagert ist? (Februar 2022)
++ 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 jede Seite 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.
+- 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)
+- 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.
+.
+
+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.
+- 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.
++ 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.
+.