Fix minor issues to the answers in ws16.q

ws16.q

 # https://sys.cs.fau.de/extern/lehre/ws23/sp2/pruefung/klausuren/2016w-SP-Klausur-www.pdf
+
 0 Welche Aussage zu Semaphoren ist richtig? (2017-02)
 - Die *P*-Operation eines Semaphors erhöht den Wert des Semaphors um 1 und deblockiert gegebenenfalls wartende Prozesse.
-  Nein, die *P*-Operation ([vom Niederländischen *probeer te verlagen* - versuche, zu verringern](https://en.wikipedia.org/wiki/Semaphore_(programming)#Operation_names)) verringert den Wert der Semaphore um 1 und blockiert, wenn dies den Wert unter 0 bringen würde, bis eine V-Operation aufgerufen wird.
+  Nein, die *P*-Operation ([vom Niederländischen *probeer te verlagen* - versuche, zu verringern](https://en.wikipedia.org/wiki/Semaphore_(programming)#Operation_names)) verringert den Wert der Semaphore um 1 und blockiert, wenn dies den Wert unter 0 bringen würde, bis eine V-Operation aufgerufen wird.  Daher "verwechselt" diese Frage *P* und *V*.
 + Die V-Operation eines Semaphors erhöht den Wert des Semaphors um 1 und deblockiert gegebenenfalls wartende Prozesse.
-Ja, die *V*-Operation (ursprünglich vom Niederländischen *vrijgave* - freigeben) erhöht den Wert der Semaphore um 1. Dabei wird eventuell eine wartende *P*-Operation entblockiert.
+  Ja, die *V*-Operation (ursprünglich vom Niederländischen *vrijgave* - freigeben) erhöht den Wert der Semaphore um 1.  Dabei wird eventuell eine wartende *P*-Operation entblockiert.
 - Ein Semaphor kann nur zur Signalisierung von Ereignissen, nicht jedoch zum Erreichen gegenseitigen Ausschlusses verwendet werden.
   Nein, eine binäre Semaphore (Semaphore mit Startwert 1), bei der P und V immer paarweise nacheinander aufgerufen werden, implementiert gegenseitigen Ausschluss.
 - Die V-Operation eines Semaphors kann ausschließlich von einem Thread aufgerufen werden, der zuvor mindestens eine P-Operation auf dem selben Semaphor aufgerufen hat.
-  Nein, eine Semaphore erlaubt dies im Gegensatz zu einem *mutex*.
+  Nein, eine Semaphore erlaubt dies im Gegensatz zu einem *mutex*, wo das nicht-einhalten dieser Vorschrift als Programmierfehler angesehen wird.
 .
 
 0 Welche Seitennummer und welcher Offset gehören bei einstufiger Seitennummerierung und einer Seitengröße von 1024 Bytes zu folgender logischer Adresse: `0xc01a`? (2017-02)
 - Seitennummer 0xc, Offset 0x1a
 + Seitennummer `0x30`, Offset `0x1a`
-  1024 = 2¹⁰ Byte pro Seite, d. h. 6 Bit Seitennummer, 10 Bit Offset.
-  `0xc01a = 0b1100 00|00 0001 1010` also ist der *offset* `0b00 0001 1010 = 0x1a` und die Seitennummer `0b0011 0000 = 0x30`.
+  1024 = 2<sup>10</sup> Byte pro Seite, d. h. 6 Bit Seitennummer, 10 Bit Offset.
+  `0xc01a = 0b1100 00|00 0001 1010` also ist der *Offset* `0b00 0001 1010 = 0x1a` und die Seitennummer `0b0011 0000 = 0x30`.
 - Seitennummer `0xc0`, Offset `0x1a`
-  Nein. Da hier der Offset 10 Bit und damit kein Vielfaches von 4 Bit hat, darf man nicht einfach die Hexadezimaldarstellung an der Grenze eines [*nibbles*](https://de.wikipedia.org/wiki/Nibble) (= Halbbyte, 4 Bit, ein Zeichen in Hexadezimaldarsetllung) zerlegen. Deswegen ist hier die Seitennummer falsch.
+  Nein.  Da hier der Offset 10 Bit und damit kein Vielfaches von 4 Bit hat, darf man nicht einfach die Hexadezimaldarstellung an der Grenze eines [*nibbles*](https://de.wikipedia.org/wiki/Nibble) (= Halbbyte, 4 Bit, ein Zeichen in Hexadezimaldarsetllung) zerlegen.  Deswegen ist hier die Seitennummer falsch.
 - Seitennummer `0xc01`, Offset `0xa`
 .
 
 0 Welche Aussage über Variablen in C-Programmen ist richtig? (2017-02)
 - Lokale automatic-Variablen, die auf dem Stack angelegt werden, werden immer mit dem Wert 0 initialisiert.
-  Lokale Variablen sind uninitialisiert, bis sie (eventuell zusammen mit der Deklaration) initialisiert werden. Lesender Zugriff auf uninitialisierte Werte löst undefiniertes Verhalten aus.
-  Globale Variablen sind hingegen standardmäßig auf 0 initialisiert.
-- Wird dem Parameter einer Funktion innerhalb der Funktion ein neuer Wert zugewiesen, so ändert sich auch der Wert der Variablen, welche in der aufrufenden Funktion als Parameter angegeben wurde
-  Nein. C ist *call-by-value*, übergeben wird also tatsächlich der Wert der Variable, nicht etwa eine Referenz darauf übergeben. Dass hier beschriebene *call-by-reference*-Verhalten kann z. B. in C++ durch die Verwendung von `&` erzeugt oder in C durch *Zeiger* nachgebildet werden.
+  Lokale Variablen sind uninitialisiert, bis sie (eventuell zusammen mit der Deklaration) initialisiert werden.  Lesender Zugriff auf uninitialisierte Werte ist undefiniertes Verhalten.
+  Globale _modul-interne_ Variablen (`static`) sind hingegen standardmäßig auf 0 initialisiert.
+- Wird dem Parameter einer Funktion innerhalb der Funktion ein neuer Wert zugewiesen, so ändert sich auch der Wert der Variablen, welche in der aufrufenden Funktion als Parameter angegeben wurde.
+  Nein.  C ist *call-by-value*, übergeben wird also tatsächlich der Wert der Variable, nicht etwa eine Referenz darauf übergeben.  Dass hier beschriebene *call-by-reference*-Verhalten kann z. B. in C++ durch die Verwendung von `&` ([References](https://en.cppreference.com/w/cpp/language/reference)) oder in Ada mit [IN OUT](http://www.ada-auth.org/standards/22rm/html/RM-6-2.html) Parameter erzeugt oder in C durch *Zeiger* nachgebildet werden.
 + Eine Funktion, die mit dem Schlüsselwort static definiert wird, kann nur innerhalb des Moduls aufgerufen werden, in dem sie definiert wurde, nicht jedoch aus einem anderen Modul heraus.
-  Ja. `static` bei Funktionen und globalen Variablen verändert die Sichtbarkeit wie hier beschrieben. (`static` bei lokalen Variablen in Funktionen sorgt dafür, dass der Wert der Variablen Funktionsaufrufe hinweg erhalten bleibt.)
+  Ja.  `static` bei Funktionen und globalen Variablen verändert die Sichtbarkeit wie hier beschrieben.  (`static` bei lokalen Variablen in Funktionen sorgt dafür, dass der Wert der Variablen Funktionsaufrufe hinweg erhalten bleibt.)  Es ist dennoch möglich einen Zeiger auf die Funktion an andere Module zu übergeben, womit man den indirekten Aufruf einer `static` Funktion erlaubt.
 - Es ist nicht möglich, Zeiger als Parameter an Funktionen zu übergeben.
   Nein, das ist möglich.
 .
@@ -36,59 +37,59 @@ Ja, die *V*-Operation (ursprünglich vom Niederländischen *vrijgave* - freigebe
 - Bei allen Monitorkonzepten (*Hansen, Hoare, Mesa*) verlässt der Prozess, der den Eintritt eines Ereignisses anzeigt (Signalgeber), den Monitor unmittelbar nach der Signalisierung.
   Nein, das ist nur bei *Hansen* und *Hoare* der Fall, bei *Mesa* kann der Signalgeber im Monitor fortfahren. (vgl. [SP2 Kapitel 10.2 S. 13](https://sys.cs.fau.de/extern/lehre/ws23/sp2/vorlesung/folien/SP2-102-A4.pdf))
 + Wartet ein Prozess in einem Monitor auf ein Ereignis, so muss er den Monitor während der Wartezeit zwingend freigeben, um einer Verklemmung vorzubeugen.
-  Ja. Sonst könnte kein anderer Prozess den Monitor betreten, um die Wartebedingung aufzuheben. Vergleiche z. B. blockierende Warteschlange. Würde hier der Konsument den Monitor nicht freigeben, so könnte ein Produzent kein Element einfügen, es liegt also eine Verklemmung vor.
+  Ja.  Sonst könnte kein anderer Prozess den Monitor betreten, um die Wartebedingung aufzuheben.  Vergleiche z. B. blockierende Warteschlange.  Würde hier der Konsument den Monitor nicht freigeben, so könnte ein Produzent kein Element einfügen, es liegt also eine Verklemmung vor.
 - Ein Monitor nach Hansen befreit bei der Signalisierung höchstens einen der wartenden Prozesse.
-  Nein, ein Monitor nach *Hansen* setzt alle Signalnehmer auf "bereit". Dadurch müssen Signalnehmer auch im kritischen Abschnitt erneut überprüfen, ob die Wartebedingung noch gilt (vgl. Semaphore bei *jbuffer*). Ein Monitor nach *Hoare* setzt im Gegensatz dazu nur genau einen Signalnehmer auf "bereit". (vgl. Folie)
+  Nein, ein Monitor nach *Hansen* setzt alle Signalnehmer auf "bereit".  Dadurch müssen Signalnehmer auch im kritischen Abschnitt erneut überprüfen, ob die Wartebedingung noch gilt (vgl. Semaphore bei *jbuffer*). Ein Monitor nach *Hoare* setzt im Gegensatz dazu nur genau einen Signalnehmer auf "bereit". (vgl. Folie)
 - Wird einem Prozess durch einen Monitor nach Hoare die Aufhebung seiner Wartebedingung signalisiert, so wird die Bedingung erneut ausgewertet; falsche Signalisierungen können also toleriert werden.
-  Nein, bei einem Monitor nach *Hoare* wird genau ein Prozess auf bereit gesetzt. Der Prozess darf also davon ausgehen, dass die Bedingung erfüllt ist (sonst wäre nicht signalisiert worden) und nicht nebenläufig von einem anderen Prozess wieder verändert wurde, bevor er den kritischen Abschnitt betreten hat. Man betrachte hier z. B. das Beispiel *blocking queue*. Im Modell *Hoare* ist beim Aufwecken eines Konsumententhreads garantiert, dass ein Element in die Warteschlange gelegt wurde. Zudem wurde nur höchstens ein Konsumententhread aufgeweckt, also wurde das Element noch nicht herausgenommen. Der Konsument (Signalnehmer) darf also den Monitor betreten und das Element entnehmen, ohne im kritischen Abschnitt zu überprüfen, ob ein anderer Konsument schneller war. Ein falsches Signal könnte hier dazu führen, dass aus einer leeren Warteschlange entnommen wird.
+  Nein, bei einem Monitor nach *Hoare* wird genau ein Prozess auf bereit gesetzt.  Der Prozess darf also davon ausgehen, dass die Bedingung erfüllt ist (sonst wäre nicht signalisiert worden) und nicht nebenläufig von einem anderen Prozess wieder verändert wurde, bevor er den kritischen Abschnitt betreten hat.  Man betrachte hier z. B. das Beispiel *blocking queue*.  Im Modell *Hoare* ist beim Aufwecken eines Konsumententhreads garantiert, dass ein Element in die Warteschlange gelegt wurde.  Zudem wurde nur höchstens ein Konsumententhread aufgeweckt, also wurde das Element noch nicht herausgenommen.  Der Konsument (Signalnehmer) darf also den Monitor betreten und das Element entnehmen, ohne im kritischen Abschnitt zu überprüfen, ob ein anderer Konsument schneller war.  Ein falsches Signal könnte hier dazu führen, dass aus einer leeren Warteschlange entnommen wird.
 .
 
 0 Welche der folgenden Aussagen über UNIX-Dateisysteme ist richtig? (2017-02)
 - Der Name einer Datei wird in ihrem Dateikopf (*inode*) gespeichert.
-  Nein, der Name wird in dem Verzeichnis gespeichert, das die Datei enthält. Es können auch mehrere Verzeichnisse Einträge mit unterschiedlichen Namen haben, die auf dieselbe *inode* verweisen.
+  Nein, der Name wird in dem Verzeichnis gespeichert, das die Datei enthält.  Es können auch mehrere Verzeichnisse Einträge mit unterschiedlichen Namen haben, die auf dieselbe *inode* verweisen.
 - In einem Verzeichnis darf es keinen Eintrag geben, der auf das Verzeichnis selbst verweist.
-  Nein. Jedes Verzeichnis enthält sogar mindestens einen solchen Eintrag (`.`).
-- Auf eine Datei in einem Dateisystem verweisen immer mindestens zwei *hard-links*
-  Nein, auf eine reguläre Datei muss nur mindestens ein *hard link* verweisen, damit sie nicht gelöscht wird. Die Aussage gilt nur für Verzeichnisse, die immer einen Verweis auf sich selbst (`.`) beinhalten und den Verweis des Elternverzeichnisses innehaben.
+  Nein.  Jedes Verzeichnis enthält sogar mindestens einen solchen Eintrag (`.`, der Selbstverweis).
+- Auf eine Datei in einem Dateisystem verweisen immer mindestens zwei *hard-links*.
+  Nein, auf eine reguläre Datei muss nur mindestens ein *hard link* verweisen, damit sie nicht gelöscht wird.  Die Aussage gilt nur für Verzeichnisse, die immer einen Verweis auf sich selbst (`.`) beinhalten und den Verweis des Elternverzeichnisses innehaben.
 + Innerhalb eines Verzeichnisses können mehrere Verweise auf den selben *inode* existieren, sofern diese unterschiedliche Namen haben.
-  Ja, das kann z. B. mit `ln datei a & ln datei b` für eine Datei `datei` im aktuellen Arbeitsverzeichnis erzielt werden.
+  Ja, das kann z. B. mit `ln datei auch-datei` für eine Datei `datei` im aktuellen Arbeitsverzeichnis erzielt werden, indem die neue Datei `auch-datei` erstellt wird welches sich die gleiche *inode* teilt.
 .
 
 1 Welche der folgenden Aussagen zum Thema persistenter Datenspeicherung sind richtig? (2017-02)
 - Bei kontinuierlicher Speicherung ist es immer problemlos möglich, bestehende Dateien zu vergrößern.
   Nein, eventuell ist der Platz nach dem Ende der Datei bereits belegt, weswegen sie nicht *in-place* vergrößert werden kann.
 - Bei indizierter Speicherung kann es prinzipbedingt nicht zu Verschnitt kommen.
-  Nein, hier ist einer Datei eine bestimmte Anzahl an Blöcken zugeordnet. Ist die Datei kleiner als diese Blöcke, so liegt Verschnitt vor.
+  Nein, hier ist einer Datei eine bestimmte Anzahl an Blöcken zugeordnet.  Ist die Datei kleiner als diese Blöcke, so liegt Verschnitt vor.
 + Bei verketteter Speicherung mittels FAT-Ansatz kann die Verkettungsinformation redundant gespeichert werden, um die Fehleranfälligkeit zu reduzieren.
   Ja, das ist möglich.
 - Im Vergleich zu den anderen Verfahren ist bei indizierter Speicherung die Positionierzeit des Festplatten-Armes beim Zugriff auf alle Datenblöcke einer Datei minimal.
-  Nein, das wäre bei sequentieller Speicherung der Fall. Die Blöcke einer Datei bei indizierter Speicherung liegen nicht notwendigerweise nah beieinander.
+  Nein, das wäre bei sequentieller Speicherung der Fall.  Die Blöcke einer Datei bei indizierter Speicherung liegen nicht notwendigerweise nah beieinander.
 + Beim Einsatz von RAID 1 kann eine der beteiligten Platten ausfallen, ohne dass das Gesamtsystem ausfällt.
-  Ja, RAID 1 verteilt die Daten redundant über zwei oder mehr Platten. Fällt eine Platte aus, so gibt es noch mindestens eine Kopie.
+  Ja, RAID 1 verteilt die Daten redundant über zwei oder mehr Platten.  Fällt eine Platte aus, so gibt es noch mindestens eine Kopie.
 - Beim Einsatz von RAID 0 kann eine der beteiligten Platten ausfallen, ohne dass das Gesamtsystem ausfällt.
   Nein, RAID 0 verteilt die Daten per *striping* nicht redundant auf die Platten, sondern erzielt nur einen Geschwindigkeitsvorteil, dadurch dass auf mehrere Platten gleichzeitig geschrieben oder von mehreren Platten gleichzeitig gelesen werden kann.
 + Journaling-Dateisysteme garantieren, dass auch nach einem Systemausfall alle Metadaten wieder in einen konsistenten Zustand gebracht werden können.
   Ja, auch die Transaktionalität der Änderung von Metadaten wird dadurch erzielt, dass Beginn und Fertigstellung aller Änderungen am Dateisystem in einem Journal aufgezeichnet werden, das beim Hochfahren auf Vollständigkeit aller Transaktionen überprüft wird.
 + Festplatten eignen sich besser für sequentielle als für wahlfreie Zugriffsmuster.
-  Ja, bei Festplatten (*HDD*s) muss auf physikalischer Ebene der Lese-/Schreibarm sich an der Stelle befinden, an der die gewünschten Daten auf der Magnetscheibe stehen. Bei wahlfreiem Zugriff muss dieser zwischen den nicht beieinanderliegenden Sektoren bewegt werden, bei sequentiellem Zugriff kann entlang der Spur gelesen werden.
+  Ja, bei Festplatten (*HDD*s) muss auf physikalischer Ebene der Lese-/Schreibarm sich an der Stelle befinden, an der die gewünschten Daten auf der Magnetscheibe stehen.  Bei wahlfreiem Zugriff muss dieser zwischen den nicht beieinanderliegenden Sektoren bewegt werden, bei sequentiellem Zugriff kann entlang der Spur gelesen werden.
 .
 
 1 Welche der folgenden Aussagen zur Einplanung von Prozessen sind richtig? (2017-02)
 + Bei kooperativer Einplanung kann es zur Monopolisierung der CPU kommen
-  Ja, bei kooperativer Einplanung muss das Programm per Systemaufruf die Ressource CPU abgeben. Ein unkooperatives Programm kann dies unterlassen, und die CPU monopolisieren.
+  Ja, bei kooperativer Einplanung muss das Programm per Systemaufruf die Ressource CPU abgeben.  Ein unkooperatives Programm kann dies unterlassen, und die CPU monopolisieren.
 - Bei der Verwendung des Round-Robin-Verfahrens kann der Konvoi-Effekt nicht auftreten.
-  Nein, der Konvoieffekt existiert auch hier, da die Vergabe der Zeitscheiben reihum wie bei *FCFS* funktioniert. Prozesse mit langen Rechenstößen nutzen hier ihre Zeitscheibe voll aus, während E/A-intensive Prozesse benachteiligt sind.
+  Nein, der Konvoieffekt existiert auch hier, da die Vergabe der Zeitscheiben reihum wie bei *FCFS* funktioniert.  Prozesse mit langen Rechenstößen nutzen hier ihre Zeitscheibe voll aus, während E/A-intensive Prozesse benachteiligt sind.
 + Der Einsatz des *FCFS*-Verfahrens setzt kooperative Prozesse voraus.
-  Ja, *FCFS* ist ein kooperatives Einplanungsverfahren. Ein unkooperativer Prozess könnte hier die CPU monopolisieren.
+  Ja, *FCFS* ist ein kooperatives Einplanungsverfahren.  Ein unkooperativer Prozess könnte hier die CPU monopolisieren.
 - Die Verwendung probabilistischer Einplanungsverfahren ist nur möglich, wenn dem Planer alle Prozesse und ihre CPU-Stoßlängen im Voraus bekannt sind.
   Nein, probabilistische Einplanungsverfahren arbeiten mit Abschätzungen der benötigten Stoßlängen.
 + In einem asymmetrischen Multiprozessorsystem ist der Einsatz asymmetrischer Einplanungsverfahren obligatorisch.
-  Ja. Man betrachte z. B. den Fall CPU + GPU. Ein Prozess, der auf der CPU rechnen möchte, kann nicht unbedingt auch auf der GPU rechnen. Deswegen ist der Einsatz einer Bereitliste für
-  alle Rechenkerne (symmetrisches Planungsverfahren) hier unmöglich. Stattdessen müssen zumindest für GPU und CPU separate Bereitlisten existieren. Dies zeichnet asymmetrische Planungsverfahren aus.
+  Ja.  Man betrachte z. B. den Fall CPU + GPU.  Ein Prozess, der auf der CPU rechnen möchte, kann nicht unbedingt auch auf der GPU rechnen.  Deswegen ist der Einsatz einer Bereitliste für
+  alle Rechenkerne (symmetrisches Planungsverfahren) hier unmöglich.  Stattdessen müssen zumindest für GPU und CPU separate Bereitlisten existieren.  Dies zeichnet asymmetrische Planungsverfahren aus.
 - Statische (off-line) Einplanungsverfahren sind besonders für den Einsatz in interaktiven Systemen geeignet.
-  Nein. *offline* Algorithmen sind alle Eingabedaten wie z. B. die zu planenden Prozesse im Voraus bekannt. Damit sind sie für interaktiven Betrieb ungeeignet, da dort zur Laufzeit vorher unbekannte Anforderungen auftreten.
+  Nein.  *offline* Algorithmen sind alle Eingabedaten wie z. B. die zu planenden Prozesse im Voraus bekannt.  Damit sind sie für interaktiven Betrieb ungeeignet, da dort zur Laufzeit vorher unbekannte Anforderungen auftreten.
 - Virtual-Round-Robin benachteiligt E/A-intensive Prozesse zu Gunsten von rechenintensiven Prozessen.
-  Nein. Bei *VRR* werden Prozesse, die eine Ein- oder Ausgabe beenden, bevorzugt eingeplant. Bei Ende einer Zeitscheibe werden dann zuerst die Prozesse auf der Vorzugsliste eingelastet.
+  Nein.  Bei *VRR* werden Prozesse, die eine Ein- oder Ausgabe beenden, bevorzugt eingeplant.  Bei Ende einer Zeitscheibe werden dann zuerst die Prozesse auf der Vorzugsliste eingelastet.
 + Beim Einsatz des multilevel-queue-Verfahrens (MLQ) werden die Prozesse nach ihrem Typ in separate Bereitlisten aufgeteilt, die jeweils eine eigene lokale Einplanungsstrategie verwenden.
-  Ja, bei diesem Verfahren werden mehrere Bereitlisten für unterschiedliche Arten von Prozessen (z. B. System-, Dialog- und Stapelprozesse) verwendet. Jede dieser Listen verwendet eine lokale Einplanungsstrategie. (Um zwischen den Listen zu wechseln wird zusätzlich eine globale Strategie verwendet).
+  Ja, bei diesem Verfahren werden mehrere Bereitlisten für unterschiedliche Arten von Prozessen (z. B. System-, Dialog- und Stapelprozesse) verwendet.  Jede dieser Listen verwendet eine lokale Einplanungsstrategie. (Um zwischen den Listen zu wechseln wird zusätzlich eine globale Strategie verwendet).
 .