ws20.q

-# https://sys.cs.fau.de/extern/lehre/ws23/sp2/pruefung/klausuren/2020w-SP-Klausur_www.pdf

ws21.q

-# https://sys.cs.fau.de/extern/lehre/ws23/sp2/pruefung/klausuren/2022w-SP-Klausur_www.pdf
-
-0 Welche der folgenden Aussagen zu statischem bzw. dynamischem Binden ist richtig? (2022-02)
-
-- Statisch gebundene Programmdateien sind kleiner als dynamisch gebundene, da mehrfach genutzte Funktionen in einer shared library abgelegt werden und nicht in die ausführbare Datei kopiert werden
-
-  Die Beschreibung trifft auf dynamisch gebundene Programmdateien,
-  weil Bibliotheksfunktionen zur Laufzeit auf `.so` Dateien laden, im
-  gegensatz zu statisch gebundenen Programmen, wo diese jedes mal zum
-  Bindezeitpunkt in die ausführbare Datei kopiert werden.
-
-+ Bei dynamischem Binden können Fehlerkorrekturen in Bibliotheken leichter übernommen werden, da nur die Bibliothek selbst neu erzeugt werden muss. Programme, die die Bibliothek verwenden, müssen nicht neu kompiliert und gebunden werden.
-
-  Ja.  Im Gegensatz dazu, müsste man bei einem statischen Bibliothek
-  alle Programme nochmal neu, gegen die aktualisierte Bibliothek
-  bauen, damit diese die neuste Version benutzen.
-
-- Beim statischen Binden werden alle Adressen zum Ladezeitpunkt aufgelöst
-
-  Nein, Adressen werden alle beim Binden aufgelöst, und sind somit
-  unabhängig von der Ausführung -- *statisch* -- bekannt.
-
-- Bei dynamischem Binden müssen zum Übersetzungszeitpunkt alle Adressbezüge vollständig aufgelöst werden
-
-  Nein, Bibliotheksfunktionen welche aus *Shared Object* Dateien
-  geladen werden können zur Laufzeit, müssen nicht beim Übersetzen
-  bereits aufgelöst geworden sein.
-.
-
-0 Welche Antwort trifft für die Eigenschaften eines UNIX/Linux-Dateideskriptor zu? (2022-02)
-
-- Ein Dateideskriptor ist eine Integerzahl, die über gemeinsamen Speicher an einen anderen Prozess übergeben werden kann, und von letzterem zum Zugriff auf eine geöffnete Datei verwendet werden kann.
-
-  Nein, es ist zwar eine Ganzzahl, aber diese kann nicht beliebig hin und her gereicht werden, zumindest ohne dass das Betriebsystem entsprechend informiert wird (siehe `sendmsg(2)`).
-
-- Dateideskriptoren sind Zeiger auf Betriebssystemstrukturen, die von den Systemaufrufen ausgewertet werden, um auf Dateien zuzugreifen.
-
-  Nein, es handelt sich nicht um einen Zeiger im gewöhnlichen Sinne (eine Adresse auf eine Speicherstelle), auch wenn es üblicherweise dazu benutzt wird um eine Prozess-Lokale Datei Tabelle zu Adressieren.  Es stimmt aber, dass es dazu benutzt wird, einem Systemaufruf eine Datei anzudeuten, auf dem dieses arbeiten soll.
-
-+ Ein Dateideskriptor ist eine prozesslokale Integerzahl, die der Prozess zum Zugriff auf eine Datei, ein Gerät, einen Socket oder eine Pipe benutzen kann.
-
-  Ja, ein Dateideskriptor muss nicht nur auf "gewöhnlichen" Dateien arbeiten, sondern kann verschieden "Datei-Ähnlichen" Objekten (d.h. Datenströmen) abstrahieren.  Wichtig ist auch der Punkt "prozesslokal", weil die Zahl nur eine Bedeutung hat, wenn das Betriebsystem dem Prozess diese Zahl zuvor explizit vergeben hat.
-
-- Beim Öffnen ein und derselben Datei erhält ein Prozess jeweils die gleiche Integerzahl als Dateideskriptor zum Zugriff zurück.
-
-  Nein, es ist möglich eine Datei Mehrfach zu öffnen, und dabei mehrere Dateideskriptoren zu bekommen.  Versuche
-
-  ~~~
-  #include <fcntl.h>
-  #include <unistd.h>
-  #include <stdio.h>
-
-  int main()
-  {
-       int fd1 = open("/etc/passwd", O_RDONLY);
-       int fd2 = open("/etc/passwd", O_RDONLY);
-
-       printf("fd1: %d, fd2: %d\n", fd1, fd2);
-  }
-  ~~~
-.
-
-1 Man unterschiedet zwei Kategorien von Ausnahmesituationen bei einer Programmausführung: Traps und Interrupts. Welche der folgenden Aussagen sind zutreffend? (2022-02)
-
-+ Ein Programm darf im Rahmen einer Trapbehandlung abgebrochen werden.
-
-  Ja, Beispielsweise bei einem ungültigem Speicherzugriff.
-
-- Ein durch einen Interrupt unterbrochenes Programm darf je nach der Interruptursache entweder abgebrochen oder fortgesetzt werden.
-
-  Nein, weil ein Interrupt nichts mit dem Programm zu tun hat, und
-  daher dieses nicht (direkt) abbrechen sollte.
-
-- Bei einem Trap wird der gerade in Bearbeitung befindliche Maschinenbefehl immer noch vollständig zu Ende bearbeitet, bevor mit der Trapbehandlung begonnen wird.
-
-  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
-  das "Hauptprogramm" vom Betriebsystem.  Der Prozessorzustand muss
-  dafür vermerkt worden sein, damit es danach wieder restauriert
-  werden kann.
-
-+ Die Ausführung einer Ganzzahl-Rechenoperation (z. B. Addition, Division) kann zu einem Trap führen.
-
-  Ja, eine Rechnerarchitektur kann beim Teilen durch 0 ein Trap auslösen.
-
-- Da Traps immer synchron auftreten, kann es im Rahmen ihrer Behandlung nicht zu Wettlaufsituationen mit dem unterbrochenen Programm kommen.
-
-  Nein, weil Traps eben immer syncrhron auftreten, gibt es keine
-  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.
-.
-
-0 In welcher der folgenden Situationen wird ein Prozess vom Zustand laufend in den Zustand bereit übeführt? (2022-02)
-
-- Der Prozess ruft die Bibliotheksfunktion `exit(3)` auf.
-
-  Nein, weil danach der Prozess nicht mehr "bereit" ist (d.h. wieder eingelagert werden kann).
-
-+ Der Scheduler bewirkt, dass der Prozess durch einen anderen Prozess verdrängt wird.
-
-  Ja, weil die einzige Ressource welche dem Prozess fehlt ist die CPU, welche der Scheduler später wieder "vergeben" kann, und damit der Prozess auch die ganze Zeit bereit ist wieder weiter zu laufen. 
-
-- Der Prozess greift lesend auf eine Datei zu und der entsprechende Datenblock ist noch nicht im Hauptspeicher vorhanden.
-
-  Nein, weil dann idr. der Prozess beendet wird mit einem Sigal wie `SIGSEVG`, und nicht mehr laufen darf.  
-
-- Der Prozess ruft eine P-Operation auf einen Semaphor auf, welcher den Wert 0 hat.
-
-  Nein, weil dann der Prozess blokiert wird, und nicht mehr laufen kann, bis an einer anderen Stelle eine entsprechende V-Operation ausgeführt wird.
-.
-
-0 Welche Aussage zum Thema Adressraumverwaltung ist richtig? (2022-02)
-+ 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 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. Das ist möglich, weil das Betriebsystem den Speicher für jeden Prozess virtualisiert und damit auch in der Lage ist, ihm diese Ressource zu entziehen.
-- Mit Hilfe des Systemaufrufes malloc() kann ein Programm zusätzliche Speicherblöcke von sehr feinkörniger Struktur vom Betriebssystem anfordern.
-  Nein, `malloc(3)` ist kein Systemaufruf, sondern eine Bibliotheksfunktion. Außerdem fordert die Laufzeitumgebung (*libc*) den Speicher üblicherweise 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 aufteilen und zurückgeben.
-.
-
-0 Sie kennen den Translation-Lookaside-Buffer (TLB). Welche Aussage ist richtig? (2022-02)
-- 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.
-- 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? (2022-02)
-- 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 Systemkernfaden (*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? (2022-02)
-+ 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 jeden Seitendeskriptor 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, sondern ist nur für die Adressabbildung von logischen zu realen Adressen zuständig.
-- 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 Speichervirtualisierung ein. Diese ist eine Aufgabe des Betriebssystems und nicht der einzelnen Benutzerprogramme.
-.
-
-0 Welche der folgenden Aussagen zum Thema Seitenfehler (*Page Fault*) ist richtig? (2022-02)
-- 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. Im Gegensatz dazu wird bei Segmentierung überprüft, ob die logische Adresse im Speichersegment liegt, das dem Prozess zugeordnet ist. Dort könnte also ein derartiger Fehler auftreten.
-- 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. Zudem löst die MMU ein Trap aus, welches später zur Zustellung eines Signals führen kann. Jedoch schickt sie nicht selbst Signale an Prozesse.
-+ 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, wird er terminiert.
-.

ws22.q

-# https://sys.cs.fau.de/extern/lehre/ws23/sp2/pruefung/klausuren/2022w-SP-Klausur_www.pdf
-
-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.
-+ 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? (2023-02)
-- Änderungen am Code einer dynamischen Bibliothek (z. B. Bugfixes) erfordern immer das erneute Binden aller Programme, die diese Bibliothek benutzen.
-  Nein. 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.
-.
-
-0 Sie kennen den Translation-Lookaside-Buffer (TLB). Welche Aussage ist richtig? (2023-02)
-+ Verändert sich die Speicherabbildung von logischen auf physikalische Adressen aufgrund einer Adressraumumschaltung, so werden auch die Daten im TLB ungültig.
-  Ja, weil die zwischengespeicherten Seitenaddressen nicht mehr mit dem neuem logischem Addressraum zusammenhängen würden.
-- Der TLB verkürzt die Zugriffszeit auf den physikalischen Speicher da ein Teil des möglichen Speichers in einem schnellen Pufferspeicher vorgehalten wird.
-  Nein, im TLB werden nur die Addressen der Seiten gespeichert, um das Nachschlagen in der MMU zu vermeiden, und nicht den Speicher selbst. 
-- Der TLB puffert Daten bei der Ein-/Ausgabebehandlung und beschleunigt diese damit.
-  Nein, der TLB hat nichts mit den Daten per se zu tun, sondern beschleundigt nur den Zugriff auf häufig benutzte Seiten.
-- 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.
-.
-
-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 ist dem Scheduler ganz überlassen zu entscheiden, auf welchen Prozessoren ein Prozess laufen soll.  Ein Prozess muss auch nicht ganz auf einem Kern oder nur auf einem Kern laufen
-+ Der Aufruf von `fork()` gibt im Elternprozess die Prozess-ID des Kindprozesses zurück, im Kindprozess hingegen den Wert 0.
-  Ja, das steht auch so in der Man Page.  Die Annahme ist hier, dass kein Fehler aufgetreten ist.
-- Threads, die mittels `pthread_create()` erzeugt wurden, besitzen jeweils einen eigenen Adressraum.
-  Nein, Kind-Threads (im Kontext von der Pthread Bibliothek.) teilen den Addressraum mit dem Eltern-Thread.  Prozesse haben eigene Addressräume.
-- Die Veränderung von Variablen und Datenstrukturen in einem mittels `fork()` erzeugten Kindprozess beeinflusst auch die Datenstrukturen im Elternprozess.
-  Nein, allgemein nicht, außer der Benutzer richtet dieses spezifisch ein (Siehe `shm_open(3)`), was aber ohne weiteres nicht der Fall ist.
-.
-
-0 Was ist ein Stack-Frame? (2023-02)
-- Der Speicherbereich, in dem der Programmcode einer Funktion abgelegt ist.
-  Nein, ein Stack-Frame liegt im Stack Segment, und der Programmcode liegt im Text-Segment.
-- Ein Fehler, der bei unberechtigten Zugriffen auf den Stack-Speicher entsteht.
-  Nein, es gibt keinen gesonderten Namen für Fehlerhaften Zugriff auf den Stack-Namen.
-+ Ein Bereich des Speichers, in dem u.a. lokale automatic-Variablen einer Funktion abgelegt sind.
-  Ja, ein Stack-Frame wird beim betreten einer Funktion angelegt für alle Metadaten und Daten welche zur ausführung benötigt werden und aufgeräumt sobald die Funktion verlassen wird.
-- Ein spezieller Registersatz des Prozessors zur Bearbeitung von Funktionen.
-  Nein, es ist kein Registersatz.
-.
-
-0 Welche der folgenden Informationen wird typischerweise in dem Seitendeskriptor einer Seite eines virtuellen Adressraums gehalten? (2023-02)
-+ Die Zugriffsrechte auf die jeweilige Seite (z. B. lesen, schreiben, ausführen).
-  Ja, so setzt das Betriebsystem bspw. um, dass ein Text Segment ausführbar aber nicht schreibbar ist.
-- Die Identifikation des Prozesses, dem die Seite zugeordnet ist.
-  Nein, das Seiten existieren unabhängig von Prozessen und müssten per se nicht dafür benutzt werden, um logische Speicherräume auf Betriebsystemen mit unabhängigen Prozessen umzusetzen.
-- Die Zuordnung zu einem Segment (Text, Daten, ...).
-  Nein, dieses wird muss man sich nicht in dem Seitendeskriptor merken, weil es nur wichtig ist, dass die Seite sich gemäß dem Verständniss von diesen Segmenten verhällt (lesbar, ausfübar, ...).
-- Die Position der Seite im virtuellen Adressraum.
-  Nein, diese Zuordnung findet nicht im Seitendeskriptor statt, sondern im Betriebsystem.
-.