From 518dc1fedcc9b85bcada5f9881b6750c6563090e Mon Sep 17 00:00:00 2001 From: "Maximilian R." <maxi.rostock@outlook.de> Date: Wed, 10 Jan 2024 19:49:13 +0100 Subject: [PATCH] wrong file --- ws22.q | 33 --------------------------------- ws23.q | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 33 deletions(-) create mode 100644 ws23.q diff --git a/ws22.q b/ws22.q index 5c60f0a..8707009 100644 --- a/ws22.q +++ b/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. -. diff --git a/ws23.q b/ws23.q new file mode 100644 index 0000000..4fbe007 --- /dev/null +++ b/ws23.q @@ -0,0 +1,32 @@ +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 -- GitLab