Fixes from review

ws23.q

@@ -11,22 +11,22 @@
 
 0 Welche Aussage zum Thema Synchronisation ist richtig? (2023-02)
 - Die V-Operation kann auf einem Semaphor nur von dem Thread aufgerufen werden, der zuvor auch die P-Operation aufgerufen hat.
-  Nein, P und V können von beliebigen, auch unterschiedlichen, Threads aus aufgerufen werden. Vergleiche ~jbuffer~.
+  Nein, P und V können von beliebigen, auch unterschiedlichen, Threads aus aufgerufen werden.
 + Durch den Einsatz von Semaphoren kann ein wechselseitiger Ausschluss erzielt werden.
-  Ja, eine Semaphore mit initialem Wert von 1 implementiert *mutual exclusion*, wenn P und V immer paarweise nacheinander aufgerufen werden.
+  Ja, eine Semaphore mit initialem Wert von 1 (binäre Semaphore) implementiert *mutual exclusion*, wenn P und V immer paarweise nacheinander aufgerufen werden.
 - Ein Semaphor kann ausschließlich für mehrseitige Synchronisation (*multilateral synchronisation*) verwendet werden.
-  Nein, das würde bedeuten, dass man damit nur Synchronisationsmechanismen implementieren kann, bei denen jeder Zugriff und nicht nur Entnahmezugriffe auf das Betriebsmittel dem wechselseitigen Ausschluss unterliegt. (vgl. [10.1 S.14]) Jedoch lässt sich z. B. eine blockierende Warteschlange mit nichtblockierender Entnahme implementieren, bei welcher die Semaphore nur Konsumenten bei einer leeren Warteschlange blockiert
+  Nein, das würde bedeuten, dass man damit nur Synchronisationsmechanismen implementieren kann, bei denen jeder Zugriff und nicht nur Entnahmezugriffe auf das Betriebsmittel dem wechselseitigen Ausschluss unterliegt. (vgl. [10.1 S.14]) Jedoch lässt sich z. B. eine blockierende Warteschlange mit nichtblockierender Entnahme implementieren, bei welcher die Semaphore nur Konsumenten bei einer leeren Warteschlange blockiert.
 - Einseitige Synchronisation (*unilateral synchronisation*) erfordert immer Betriebssystemunterstützung.
-  Nein, diese kann im *userspace* zum Beispiel durch atomare Variablen (hier also mit Unterstützung des Prozessors) realisiert werden.
+  Nein, diese kann zum Beispiel ohne Betriebssystemaufrufe durch ein *spin lock* realisiert werden.
 .
 
 0 Welche der folgenden Aussagen zu statischem bzw. dynamischem Binden ist richtig? (2023-02)
 - Änderungen am Code einer dynamischen Bibliothek (z. B. Bugfixes) erfordern immer das erneute Binden aller Programme, die diese Bibliothek benutzen.
-  Ja, zumindest in der Theorie müssen Programme, die eine dynamische Bibliothek einbinden nur neugestartet werden, nachdem diese ausgetauscht wurde nur neugestartet werden, wonach sie durch den dynamischen Binder neu gebunden werden.
+  Ja. Programme, die eine dynamische Bibliothek einbinden müssen (zumindest in der Theorie) nur neugestartet werden, nachdem diese ausgetauscht wurde, wonach sie durch den dynamischen Binder neu gebunden werden.
 - Beim statischen Binden werden alle Adressen zum Ladezeitpunkt aufgelöst.
   Nein, das passiert hier bereits beim Binden.
 + Beim dynamischen Binden erfolgt die Adressauflösung beim Laden des Programms oder zur Laufzeit.
-  Ja, beim Laden werden die Adressen der verwendeten Symbole durch den *dynamic linker* aufgelöst. Zur Laufzeit können jedoch noch Bibliotheken nachgeladen werden (~dlopen(3)~).
+  Ja, beim Laden werden die Adressen der verwendeten Symbole durch den *dynamic linker* aufgelöst. Zur Laufzeit können jedoch noch Bibliotheken nachgeladen werden (`dlopen(3)`).
 - Statisch gebundene Programme können zum Ladezeitpunkt an beliebige virtuelle Speicheradressen platziert werden.
   Nein. Das kann, muss aber nicht so sein. Dynamische Bibliotheken müssen hingegen *position-independent-code* enthalten, um in den Adressbereich des Zielprogramms geladen werden zu können.
 .
\ No newline at end of file