Merge branch 'main' into 'main'

Add questions from 2023-02 exam

See merge request !1

ws23.q

+0 Beim Blockieren in einem Monitor muss der Monitor freigegeben werden. Warum? (Februar 2023)
+- 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 zum Thema Synchronisation ist richtig? (Februar 2023)
+- 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.
++ Durch den Einsatz von Semaphoren kann ein wechselseitiger Ausschluss erzielt 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.
+- Einseitige Synchronisation (*unilateral synchronisation*) erfordert immer Betriebssystemunterstützung.
+  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? (Februar 2023)
+- Änderungen am Code einer dynamischen Bibliothek (z. B. Bugfixes) erfordern immer das erneute Binden aller Programme, die diese Bibliothek benutzen.
+  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)`).
+- 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