Add questions and comments from 2016-02

ws15.q

+# https://sys.cs.fau.de/extern/lehre/ws23/sp2/pruefung/klausuren/2015w-SP-Klausur-www.pdf
+
+0 (2016-02) Wie funktioniert Adressraumschutz durch Eingrenzung?
+
+- Der Lader positioniert Programme immer so im Arbeitsspeicher, dass
+| unerlaubte Adressen mit nicht-existierenden physikalischen
+| Speicherbereichen zusammenfallen.
+
+  Nein, das ist nicht was mit "Eingrenzung" gemeint ist.  Ansonsten
+  wäre es recht umständlich, die Lücken im physikalischem Speicher
+  welche für Memory-Mapped I/O, den BIOS, PCI, etc. für eine dynamische
+  Anzahl an Prozessen auszunutzen.
+
+- Begrenzungsregister legen einen Adressbereich im logischen
+| Adressraum fest, auf den alle Speicherzugriffe beschränkt werden.
+
+  Nein, bei Eingrenzung ist der Addressbereich im physikalischen
+  Adressraum.
+
++ Begrenzungsregister legen einen Adressbereich im physikalischen
+| Adressraum fest, auf den alle Speicherzugriffe beschränkt werden.
+
+  Ja, Bei Eingrenzung, bzw. "Einfriedung" wird ein Teil des
+  physikalischen Speichers mittels Grenzregistern überprüft, noch
+  bevor der Addressbus angeprochen wird.
+
+- Jedes Programm bekommt zur Ladezeit mehrere Wertepaare aus Basis-
+| und Längenregistern zugeordnet, die die Größe aller Segmente des
+| darin laufenden Prozesses festlegen.
+
+  Nein, das umschreibt Segmentierung.
+.
+
+0 (2016-02) Ein Prozess wird vom Zustand blockiert in den Zustand
+| bereit überführt. Welche Aussage passt zu diesem Vorgang?
+
++ Der Prozess hat auf das Einlesen von Daten von der Festplatte
+| gewartet, die nun verfügbar sind.
+
+  Ja, die Ressource (Daten von der Festplatte) waren nicht verfügbar,
+  und waren daher Grund weshalb der Prozess im Blokiertem Zustand war.
+  Man geht nicht direkt von "Blokiert" nach "Laufend" über, sondern
+  macht den Umweg über "Bereit", d.h. der Prozess ist in der
+  Bereitliste vom Scheduler eingeordnet.
+
+? Ein Prozess, der zu einem früheren Zeitpunkt aufgrund von
+| Speichermangel auf den Hintergrundspeicher ausgelagert wurde, ist nun
+| wieder eingelagert und kann weiterlaufen.
+
+  Ich glaube das sollte falsch sein, weil ein Prozess _als solches_
+  nicht _aufgrund_ von Speichermangel in den Hintergrundspeicher
+  ausgelagert wird.
+
+- Ein anderer Prozess wurde vom Betriebssystem verdrängt und der
+| erstgenannte Prozess wird nun auf der CPU eingelastet.
+
+  Nein, dieser erstgennante Prozess wäre "Bereit" gewesen, und würde
+  nun im Zustand "Laufend" sein.  Der andere Prozess wäre den
+  Umgekehrten weg, von "Laufend" nach "Bereit" übergegangen (diesem
+  Fehlt nichts außer die CPU).
+
+- Es ist kein direkter Übergang von blockiert nach bereit möglich.
+
+  Nein, es ist kein Überganz von "Blokiert" nach "Laufend" möglich,
+  aber ein blokierter Prozess kann in "Bereit" überführt werden, sobal
+  der Grund für das Blokiertsein aufgelöst wurde.
+
+.
+
+0 (2016-02) Wodurch kann es zu Seitenflattern kommen?
+
+- Wenn die Zahl der residenten Seiten die Größe des physikalischen
+| Speichers überschreitet.
+
+  Nein, in diesem Fall würde es nur zu einer Auslagerung von Seiten
+  kommen, was aber nicht zwingend "Seitenflattern" bedingen würde.
+  
+- Durch Programme, die eine Defragmentierung auf der Platte
+| durchführen.
+
+  Nein, Seitenflattern bezeichnet das pathologische Phänomen, wenn die
+  Seitenumlagerungsstrategie eine Menge von Seiten zu häufig Umlagern
+  muss, und damit den Zugriff auf den Speicher verlangsamt.  Es an
+  sich hat nichts mit dem Dateisystem zu tun.
+
++ Wenn ein Prozess zum Weiterarbeiten immer gerade die Seiten
+| benötigt, die durch das Betriebssystem im Rahmen einer globalen
+| Ersetzungsstrategie gerade erst ausgelagert wurden.
+  
+  Ja, das ist die Definition vom Begriff.  Siehe im [Wosch
+  Glossar](https://www4.cs.fau.de/~wosch/glossar.pdf), den Eintrag
+  "Flattern".
+    
+- Wenn zu viele Prozesse im Rahmen der mittelfristigen Einplanung auf
+| den Hintergrundspeicher ausgelagert wurden (swap-out).
+
+  Nein, der Begriff ist unabhängig von der Planungsstrategie zu
+  verstehen.
+
+.
+
+0 (2016-02) Man unterscheidet bei Programmunterbrechungen
+| zwischen Traps und Interrupts. Welche Aussage dazu ist richtig?
+
+- Die Behandlung eines Traps führt immer zur Beendigung des
+| unterbrochenen Programms, da Traps nur durch schwerwiegende Fehler
+| ausgelöst werden.
+
+  Nein, Traps können auch durch Systemaufrufe (Quasi-Nachrichten an
+  das Betriebsystem) oder durch fehlende aber einlagerbare
+  Speicherseiten ausgelöst werden.
+
+- Da das Betriebssystem nicht vorhersagen kann, wann ein
+| Benutzerprogramm einen Systemaufruf absetzt, sind Systemaufrufe als
+| Interrupts zu klassifizieren.
+
+  Nein, Systemaufrufe treten immer dann deterministisch auf, wenn der
+  entsprechende Maschinenbefehl (`syscall` auf , `int` auf x86,
+  `ecall` of RISC-V).
+
++ Bei der mehrfachen Ausführung eines unveränderten Programms mit
+| gleicher Eingabe treten Traps immer an den gleichen Stellen auf.
+
+  Ja, das folgt aus dem Determinismus von Traps.
+
+- Da Interrupts in keinem Zusammenhang mit dem unterbrochenen Programm
+| stehen, muss der Prozessorstatus des unterbrochenen Programms
+| während der Behandlung nicht speziell gesichert werden.
+
+  Doch, weil die Behandlung des Interrupts den Prozessorstatus
+  durchaus beeinflusst, und damit es aber das unterbrochenen Programm
+  nicht direkt verändert (es braucht ja nur für die Behandlung die CPU
+  für eine kurze Zeit), wird vor der Behandlung der Zustand des
+  Prozessors gespeichert -- bspw. in dem dieser auf dem Stack kopiert
+  wird, dann die Unterbrechungsroutine eingeleitet wird, und danach
+  wiederhergestellt wird.
+
+.
+
+0 (2016-02) Namensräume dienen u. a. der Organisation von
+| Dateisystemen. Welche Aussage ist richtig?
+  
+- Das Arbeitsverzeichnis eines Prozesses definiert die Wurzel des
+| hierarchisch organisierten Namensraums in einem Dateisystem.
+
+  Nein, die Wurzel des Namensraums ist (zunächst, siehe `chroot(2)`)
+  fest und unabhängig von Prozessen und ihren Arbeitsverzeichnissen.
+
++ In einem hierarchisch organisierten Namensraum dürfen gleiche Namen
+| in unterschiedlichen Kontexten enthalten sein.
+
+  Ja, so kann es sowohl `/home/alice/shopping` und
+  `/home/bob/shopping` geben.  Nur in einem Verzeichnis darf _ein_
+  Name _einmal_ vergeben werden.
+
+? Flache Namensräume erlauben pro Benutzer nur einen Kontext.
+
+  Ein Benutzer hat immer nur einen Kontext, unabhängig davon ob der
+  Namensraum flach ist oder nicht.
+
+- Hierarchische Namensräume werden erzeugt, indem man in einem Kontext
+| symbolische Verweise auf Dateien einträgt.
+
+  Nein, hierarchische Namensräume können auch nur von Hardlinks
+  aufgespannt werden (wie es der Fall war bevor BSD diese für UNIX
+  implementiert hat).
+
+.
+
+0 (2016-02) Welche Aussage zu Programmbibliotheken ist richtig?
+
+- Statische Bibliotheken können in C nicht implementiert werden.
+
+  Doch, wir können eiene Menge von Obejktdateien mit `ar` zu einem
+  Archiv zusammenbinden.  Das war historisch auch der standard.
+
++ Eine Änderung am Code einer statischen Bibliothek (z. B. Bugfixes)
+| erfordert kein erneutes Binden der Programme, die diese Bibliothek
+| benutzen.
+
+  Ja, weil die Bibliotheken beim Binden des Programms eingebunden
+  werden, und gleich bleiben wenn das Archiv geändert wird.
+
+- Eine statische Bibliothek, mit der ein Programm gebunden wurde, muss
+| zum Ladezeitpunkt des Programms nicht mehr als eigenständige Datei
+| im Dateisystem vorhanden sein.
+
+  Nein, weil die Inhalte des Archivs wurden beibem Binden des Archivs
+  in die ausführbare Datei "kopiert", und werden zur ausführung aus
+  der ausführbaren Datei geladen, und nicht aus dem ursprünglichem
+  Archiv, was daher auch nicht mehr existieren muss.
+
+- Beim Binden mit einer statischen Bibliothek werden in einem Programm
+| nur Verweise auf verwendete Symbole der Bibliothek angelegt.
+
+  Nein, das wäre dynamisches Binden.  Beim statischem Binden wird der
+  gesammte Programmtext der Bibilothek im Programm kopiert.
+
+.
+
+0 (2016-02) Welche Seitennummer und welcher Versatz gehören bei
+| einstufiger Seitennummerierung und einer Seitengröße von 2048 Bytes zu
+| folgender logischer Adresse: `0xba1d`
+
++ Seitennummer `0xb`, Versatz `0xa1d`.
+
+  In binär:
+
+  - `0xba1d` ist  0b1011101000011101
+  - `0xb` ist  `0b1011`
+  - `0xa1d` ist `0b101000011101`
+
+  Wenn man die ersten 11 bit abschneidet (weil 2^11 = 2048), sieht man
+  wie die Addresse zusammengesetzt ist:
+
+  ~~~
+  1011101000011101  <- Logische Addresse
+
+  1011              <- Page Nummer
+      101000011101  <- Page Offset
+  ~~~
+
+- Seitennummer `0x17`, Versatz `0x21d`.
+- Seitennummer `0xba`, Versatz `0x1d`.
+- Seitennummer `0x2e`, Versatz `0x21d`.
+.
+
+0 (2016-02) Man unterscheidet die Begriffe Programm und
+| Prozess. Welche der folgenden Aussagen zu diesem Themengebiet ist
+| richtig?
+
+- Ein Programm kann immer nur von einem Prozess gleichzeitig
+| ausgeführt werden.
+
+  Nein, mehere Prozessinstanzen können das gleiche Programm ausführen,
+  zumindest auf einem UNIX™ System, welches keine solchen
+  Einschänkungen vorsieht.
+
+- Das Programm ist der statische Teil (Rechte, Speicher, etc.), der
+| Prozess der aktive Teil (Programmzähler, Register, Stack).
+
+  Nein, der Speicher ist auch "aktiv" an der Ausführung beteiligt,
+  aber ansonsten ist auch die Begriffsunterscheidung hier (für mich)
+  nicht klar.
+
+- Wenn ein Programm nur einen aktiven Ablauf enthält, nennt man diesen
+| Prozess, enthält das Programm mehrere Abläufe, nennt man diese
+| Threads.
+
+  Nein, der Begriff "Threads" (Fäden) verstanden als
+  "Leichtgewichtiger Prozess", beschreibt einen Ausführungsstrang,
+  welches mit anderen Threads _in einem Prozess_ den gleichen
+  Speicherraum teil.  Jedenfalls nennt man ein Programm weder Prozess
+  oder Threads (Kategorien-Fehler), sondern ein Programm wird in
+  bzw. von einem Prozess oder in einem Thread ausgeführt.
+
++ Ein Prozess ist ein Programm in Ausführung - ein Prozess kann aber
+| während seiner Lebenszeit auch mehrere verschiedene Programme
+| ausführen.
+
+  Ja, das ist die Definition.  Ein Prozess kann sein Programm mitttels
+  eines `exec` Systemaufrufs auswechseln.
+.
+
+1 (2016-02) Welche der folgenden Aussagen zum Thema
+| Seiteneinlagerungs- und Seitenersetzungsstrategien ist richtig?
+
++ Die Ersetzungsstrategie MIN ist in der Praxis nur schwer
+| realisierbar, weil Wissen über das zukünftige Verhalten des
+| Gesamtsystems notwendig ist.
+
+  Ja, MIN (oder "B0", "OPT") müsste die Referenzfolge zuvor wissen;
+  der Ansatz ist "meist nur zum Vergleich von Strategien brauchbar".
+
++ Bei der Verwendung von globalen Seitenersetzungsstrategien sind
+| Seitenfehler vorhersagbar bzw. reproduzierbar.
+
+  Nein, weil bei einer globalen Ersetzungsstrategie verhällt sich ein
+  Seitenfehler wie ein _Interrupt_, weil es nicht direkt vorhersehbar
+  ist anhand vom Verhalten des eigenen Programms.
+
+- Mit dem Systemaufruf `free()` kann eine Speicherseite in den
+| Freiseitenpuffer eingefügt werden.
+
+  Nein, mit `free()` wird im _Freispeicher_ ein reservierte
+  Speicherbereich zurück gegeben.  Es ist darüber hinaus kein
+  Systemaufruf, sondern verwaltet Speicher im Userspace.
+
++ Die Ersetzungsstrategie LRU ersetzt die am längsten nicht mehr
+| referenzierte Seite.
+
+  Ja, da Akronym LRU -- _Least Recently Used_ -- deutet darauf hin.
+
+- Bei der Verwendung von lokalen Seitenersetzungsstrategien sind
+| Seitenfehler vorhersagbar bzw. reproduzierbar.
+
+  Ja, weil bei einer lokalen Ersetzungsstrategie ist ein Seitenfehler
+  ein _Trap_.
+
+- Die Ersetzungsstrategie LRU benötigt im Vergleich zu FIFO immer
+| weniger Versuche, bis eine zu ersetzende Seite gefunden werden kann.
+
+  Nein, FIFO (_First In, First Out_) kann immer gleich bestimmen
+  welche Seite zu ersetzen ist, während man bei LRU (_Least Recently
+  Used_) erst berechnen müsste welche Seite am längsten nicht benutzt
+  wurde.
+
+- Lokale Seitenersetzungsstrategien wählen die zu ersetzende Seite
+| immer aus der Menge aller im System verfügbaren Seitenrahmen aus.
+
+  Nein, bei einer lokalen Ersetzungsstrategien, ist ein Prozess selbst
+  dafür verantwortlich seine eigenen Seiten zu ersetzen.
+  
++ Bei der Ersetzungsstrategie LFU wird die am seltensten referenzierte
+| Seite aus dem Speicher verdrängt.
+  
+  Ja, das Akronym -- _Least Frequently Used_ -- deutet darauf hin.
+.
+
+1 (2016-02) Welche der folgenden Aussagen zum Thema Synchronisation
+| sind richtig?
+
+- Ein Mutex kann ausschließlich für einseitige Synchronisation
+| verwendet werden.
+
+  Nein, ein Mutex kann auch zur mehrseitigen synchronisation bei
+  assymetrischer Nebenläufigkeit dienen (die _Mutual Exclusion_,
+  welche mit einem "Mut Ex" umgesetzt wird, wird eben oft dazu benutzt
+  um andere Handlungsstränge davon abzuhalten, einen kritischen
+  Abschnitt zu betreten, wo man unter der Annahme arbeiten will, dass
+  keine Wettlaufsituationen auftreten können).
+
+- Der Einsatz von nicht-blockierenden Synchronisationsmechanismen kann
+| zu Verklemmungen (dead-locks) führen.
+
+  Nein, ein Dead-Lock setzt voraus, dass ein Faden blockiert werden
+  kann, bspw. durch ein Mutex oder eine Semaphore, was aber nicht der
+  Fall ist bei nicht-blockierender Syncrhonisation, dessen Ansatz
+  darauf basiert atomare Befehle zu verwenden, um transaktional
+  kritische Operationen auszuführen.  Bemerke aber, dass es dennoch zu
+  einem Live-Lock, oder einem effektivem Live-Lock kommen kann, weil
+  Nicht-Blockierende synchronisation, nicht bedeutet, dass der Ansatz
+  Wartefrei/Sperrfrei/Behinderunfsfrei sein muss.
+  
++ Die V-Operation kann auf einem Semaphor auch von einem Faden
+| aufgerufen werden, der zuvor keine P-Operation auf dem selben
+| Semaphor ausgeführt hat.
+
+  Ja, im Gegensatz zu einem Mutex ist der Benutzer nicht dazu
+  gezwungen erst die Semaphore zu "sperren" (P) und dannach auf dem
+  gleichen Faden wieder "freizugeben" (V).
+
+- Ein Anwendungsprozess muss bei der Verwendung von Semaphoren
+| Interrupts sperren, um Probleme durch Nebenläufigkeit zu verhindern.
+
+  Nein, ein Anwendungsprozess kann selbst keine interrupts Sperren,
+  und unabhängig davon ist das nicht notwendig, da Semaphoren selbst
+  eine Syncrhonisationsmittel sind.
+
++ Für nichtblockierende Synchronisation werden spezielle Befehle der
+| Hardware genutzt, die wechselseitigen Ausschluss garantieren.
+
+  Ja, Operationen wie CAS (Compare and Swap), TAS (Test and Set), FFA
+  (Fetch and Add) werden bei verschienden Architekturen auf
+  verschiedene Befehle abgebildet, welche -- ohne
+  Betriebsystemunterstützung -- in der Lage sind die meist komplexen
+  Operationen atomar auszuführen.  Siehe Beispilesweise auf x86
+  [`CMPXCHG`](https://c9x.me/x86/html/file_module_x86_id_41.html),
+  [`BTS`](https://c9x.me/x86/html/file_module_x86_id_25.html) oder
+  [`XADD`](https://c9x.me/x86/html/file_module_x86_id_327.html) mit
+  dem `LOCK` prefix.  Auf anderen Architekturen (häufig RISC-artig)
+  können diese nachgebildet werden mittels
+  [Load-link/store-conditional](https://en.wikipedia.org/wiki/Load-link/store-conditional)
+  befehlen (siehe Vorlesungsfolien von der Vorlesung [Concurrent
+  Systems](https://www4.cs.fau.de/Lehre/WS19/V_CS/Vorlesung/folien/handout/5-elops.pdf)
+  für mehr zu dem Thema).
+
++ Semaphore können sowohl für einseitige als auch für mehrseitige
+| Synchronisation verwendet werden.
+
+  Ja.  Bei einseitige Synchronisation kann man zwei signalisierende
+  Semaphoren benutzen, bei mehrseitige Synchronisation ein
+  ausschließende Semaphore.
+
+- Zur Synchronisation eines kritischen Abschnitts ist passives Warten
+| immer besser geeignet als aktives Warten.
+
+  Nein, allgemein kann man das nicht sagen, weil es auch davon abhängt
+  ob man ein Betriebsystem hat, oder wie lange man erwartet zu warten,
+  wo die Kosten von passivem Warten ggf. nicht zu vernachlässigen
+  wären.
+
++ Gibt ein Faden einen Mutex frei, den er selbst zuvor nicht
+| angefordert hatte, stellt dies einen Programmierfehler dar; der
+| fehlerhafte Prozess sollte dann abgebrochen werden.
+
+  Ja, weil das die beabsichtige Verwendung einer Semaphore verletzen
+  würde, welches eben diese Benutzung vorraussetzt.
+
+.