wrong file

ws22.q

@@ -163,36 +163,3 @@
 - 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 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.
-.

ws23.q

+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 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