diff --git a/ws22.q b/ws22.q
index 87070093c814eb6f729868d0510c06b3e08fea91..263ae3518d3ce6176452f133a24b53d47ba75d54 100644
--- a/ws22.q
+++ b/ws22.q
@@ -163,3 +163,47 @@
 - Die Position der Seite im virtuellen Adressraum.
   Nein, diese Zuordnung findet nicht im Seitendeskriptor statt, sondern im Betriebsystem.
 .
+
+0 Beim Blockieren in einem Monitor muss der Monitor freigegeben werden. Warum? (2023-02)
+- Weil kritische Abschnitte immer nur kurz belegt sein dürfen.
+  Für die Performanz eines Programms ist das sicher vorteilhaft, jedoch hat das nichts mit der Frage zu tun.
+- Weil sonst die Monitordaten inkonsistent sind.
+  Nein, gegenseitiger Auschluss wäre sonst auch gegeben.
++ Weil ein anderer Thread die Blockierungsbedingung nur aufheben kann, wenn er den Monitor vorher betreten kann.
+  Ja, vergleiche z. B. blockierende Warteschlange. Würde ein konsumierender Thread nicht den Monitor freigeben, so könnte kein produzierender Thread ein Element einfügen.
+- Weil der Thread sonst aktiv warten würde.
+  Nein, der Thread wartet passiv auf den Monitor.
+.
+
+0 Welche Aussage zu Prozessen und Threads ist richtig? (2023-02)
+- Mittels ~fork()~ erzeugte Kindprozesse können in einem Multiprozessor-System nur auf dem Prozessor ausgeführt werden, auf dem auch der Elternprozess ausgeführt wird.
+  Nein, es spricht nichts dagegen, dass das Betriebssystem einen Prozess auf einem anderen Prozessor als dem urpsrünglichen einlastet.
++ Der Aufruf von ~fork()~ gibt im Elternprozess die Prozess-ID des Kindprozesses zurück, im Kindprozess hingegen den Wert 0.
+  Ja, zumindest wenn kein Fehler aufgetreten ist. Siehe ~fork(2)~.
+- Threads die mittels ~pthread_create()~ erzeugt wurden, besitzen jeweils einen eigenen Adressraum.
+  Nein. Prozesse besitzen einen eigenen Adressraum. Mehrere Threads in einem Prozess teilen sich einen Adressraum.
+-  Die Veränderung von Variablen und Datenstrukturen in einem mittels ~fork()~ erzeugten Kindprozess beeinflusst auch die Datenstrukturen im Elternprozess.
+   Nein. Der Kindprozess arbeitet auf einer Kopie des gesamten Adressraums.
+.
+
+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~.
++ 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.
+- 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
+- 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.
+.
+
+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.
+- 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)~).
+- 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