Skip to content
Snippets Groups Projects
Verified Commit 947c22fd authored by Maximilian's avatar Maximilian :notebook_with_decorative_cover:
Browse files

Add more questions

parent 53629eed
No related branches found
No related tags found
No related merge requests found
......@@ -77,7 +77,7 @@
Nein, bspw. wenn man versucht auf nicht lesbaren Speicher versucht
zuzugreifen, muss es abgebrochen werden, bevor auf den Speicher
zuggegriffen wurde.
+ Die CPU sichert bei einem Interrupt einen Teil des Prozessorzustands.
Ja, genau wie bei einer Signal-Behandlung unterbricht ein Interrupt
......@@ -95,7 +95,7 @@
Nebenläufigkeit welche Probleme bereitet.
? Wenn ein Interrupt ein schwerwiegendes Ereignis signalisiert, wird das unterbrochene Programm im Rahmen der Interruptbearbeitung immer abgebrochen.
- Ein Systemaufruf im Anwendungsprogramm ist der Kategorie Interrupt zuzuordnen.
Nein, weil diese deterministisch immer dann auftreten, wenn ein Programm ein Systemaufruf absetzen will.
......@@ -163,3 +163,58 @@
- Die Position der Seite im virtuellen Adressraum.
Nein, diese Zuordnung findet nicht im Seitendeskriptor statt, sondern im Betriebsystem.
.
0 Welche Aussage zum Thema Adressraumverwaltung ist richtig? (Februar 2022)
+ Ein Speicherbereich, der mit Hilfe der Funktion free() freigegeben wurde, verbleibt im logischen Adressraum des zugehörigen Prozesses.
Ja. Der **logische** Adressraum A = [n, m] ist der gesamte Adressbereich ohne Lücken, der einem Prozess zugeordnet wird. Dieser wird im allgemeinen nicht verkleinert, wenn `free` aufgerufen wird. Im Gegensatz dazu ist der virtuelle Adressraum A jener, der nur partiell auf den Hauptspeicher abgebildet wird, bei dem also Adressen ungültig sein können. (vgl. SP1 B Vl. 2 S. 12 ff., 27) (Bin mir hier nicht zu 100 % sicher, dass meine Interpretation korrekt ist)
- Mit malloc() angeforderter Speicher, welcher vor Programmende nicht freigegeben wurde, kann vom Betriebssystem nicht mehr an andere Prozesse herausgegeben werden und ist damit bis zum Neustart des Systems verloren.
Nein, nach dem Ende des Programms wird der gesamte Adressbereich des Prozesses freigegeben.
- Mit Hilfe des Systemaufrufes malloc() kann ein Programm zusätzliche Speicherblöcke von sehr feinkörniger Struktur vom Betriebssystem anfordern.
Nein, die Laufzeitumgebung (*libc*) fordert den Speicher grobgranular vom Betriebssystem an (`mmap(2), brk(2)`) und verteilt diesen im Benutzerprozess.
- Da das Laufzeitsystem auf die Betriebssystemschnittstelle zur Speicherverwaltung zurückgreift, ist die Granularität der von malloc() zurückgegebenen Speicherblöcke vom Betriebssystem vorgegeben.
Nein, `malloc` kann als Teil des Laufzeitsystems den grobgranular vom Betriebssystem angeforderten Speicher feingranular zurückgeben.
.
0 Sie kennen den Translation-Lookaside-Buffer (TLB). Welche Aussage ist richtig? (Februar 2022)
- Der TLB puffert die Ergebnisse der Abbildung von physikalische auf logische Adressen, sodass eine erneute Anfrage sofort beantwortet werden kann.
Nein, andersherum. Logische müssen in physikalische Adressen übersetzt werden.
+ Verändert sich die Speicherabbildung von logischen auf physikalische Addressen aufgrund einer Adressraumumschaltung, so werden auch die Daten im TLB ungültig.
Ja, da die Einträge im TLB beziehen sich auf einen bestimmten logischen Adressraum.
- Wird eine Speicherabbildung im TLB nicht gefunden, wird vom Prozessor immer eine Ausnahme (*Trap*) ausgelöst die vom Betriebssystem behandelt wird.
Nein, ist kein Eintrag im TLB zu finden, wird die Addresse von der MMU aufgelöst. PS: Die Verwendung von *Trap* wäre hier im Gegensatz zu *Interrupt* korrekt.
- Wird eine Speicherabbildung im TLB nicht gefunden, wird der auf den Speicher zugreifende Prozess mit einer Schutzraumverletzung (Segmentation Fault) abgebrochen.
Nein, ist kein Eintrag im TLB zu finden, wird die Addresse von der MMU aufgelöst. Der TLB agiert nur als *cache* für Adressübersetzungen.
.
0 Welche Aussage zu den verschiedenen Gewichtsklassen von Prozessen trifft zu? (Februar 2022)
- Schwergewichtige Prozesse sind die einzige Klasse von Prozessen, die auf einem Multiprozessorsystem echt parallel ausgeführt werden kann, da nur hier jeder Benutzerfaden einem eigenen Kernfaden zugeordnet ist.
Nein. Auch leichtgewichtigen Prozessen (*kernel-level threads*) ist ein *kernel thread* zugeordnet.
+ Federgewichtige Prozesse (*user-level threads*) blockieren sich bei blockierenden Systemaufrufen gegenseitig.
Ja, da bei federgewichtigen Prozessen mehrere Prozesse auf einen *kernel-level thread* gemultiplext werden, wird die Ausführung der aller federgewichtigen Prozesse blockiert, die auf einem *kernel-level thread* ausgeführt werden, bis dieser wieder bereit ist.
- Beim Blockieren eines schwergewichtigen Prozesses werden alle anderen schwergewichtigen Prozesse, die das selbe Progamm ausführen, ebenfalls blockiert.
Nein. Man kann mehrere Prozesse mit dem gleichen Programm ausführen.
- Zu jedem leichtgewichtigen Prozess (*kernel-level thread*) gehört ein eigener, isolierter Adressraum.
Falsch, das wären schwergewichtige Prozesse. Leichtgewichtige Prozesse wie `pthread`s teilen sich einen Adressraum.
.
0 Wie wird erkannt, dass eine Seite eines virtuellen Adressraums, auf die ein Maschinenbefehl zugreift, gerade ausgelagert ist? (Februar 2022)
+ Im Seitendeskriptor wird ein spezielles Bit geführt, das der MMU zeigt, ob eine Seite eingelagert ist oder nicht. Falls die Seite nicht eingelagert ist, löst die MMU einen Trap aus.
Ja, die *page descriptor table* enthält für jede Seite ein *valid*-Bit. Ist dieses nicht gesetzt, so wird ein *Trap* ausgelöst.
- Im Seitendeskriptor steht bei ausgelagerten Seiten eine Adresse des Hintergrundspeichers und der Speichercontroller leitet den Zugriff auf den Hintergrundspeicher um.
Nein, die MMU interagiert nicht mit dem Hintergrundspeicher.
- Das Betriebssystem erkennt die ungültige Adresse vor Ausführung des Maschinenbefehls und lagert die Seite zuerst ein bevor ein Trap passiert.
Nein, das Betriebssystem überprüft nicht jede Instruktion vor der Ausführung. (vgl. **Teil**interpretation)
- Bei Programmen, die in virtuellen Adressräumen ausgeführt werden sollen, erzeugt der Compiler speziellen Code, der vor Betreten einer Seite die Anwesenheit überprüft und ggf. die Einlagerung veranlasst.
Nein, der Compiler fügt nicht in jedes Programm eine Implementation der Speicherverwaltung ein.
.
0 Welche der folgenden Aussagen zum Thema Seitenfehler (*Page Fault*) ist richtig? (Februar 2022)
- Wenn der gleiche Seitenrahmen in zwei verschiedenen Seitendeskriptoren eingetragen wird, löst dies einen Seitenfehler aus (Gefahr von Zugriffskonflikten!).
Nein, das würde z. B. zwischen Prozessen geteilten Speicher verhindern.
- Ein Seitenfehler wird ausgelöst, wenn der Offset in einer logischen Adresse größer als die Länge der Seite ist.
Nein, dieser Fall kann per Definition nicht eintreten. Seiten haben eine Größe von 2 Byte, (bei x86-64 z. B. 4 KiB), n Byte der Adresse werden als Offset interpretiert. Somit ist dieser Fall außerhalb des überhaupt darstellbaren Wertebereichs für den Offset.
- Ein Seitenfehler zieht eine Ausnahmebehandlung nach sich. Diese wird dadurch ausgelöst, dass die MMU das Signal SIGSEGV an den aktuell laufenden Prozess schickt.
Nein, ein Seitenfehler kann auch dadurch ausgelöst werden, dass z. B. auf eine ausgelagerte Seite zugegriffen wird. Diese wird dann für den Prozess transparent eingelagert.
+ Das Auftreten eines Seitenfehlers kann dazu führen, dass der aktuell laufende Prozess in den Zustand beendet überführt wird.
Ja, wenn der Prozess auf eine ungültige Adresse zugreift, also insbesondere auch keine Seite eingelagert werden kann und das entsprechende Signal nicht abgefangen wird, kann er terminiert werden.
.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment