Prozeß: drei häufigste Zustände Prozeß: anatomische Betrachtung jeder Prozeß verfügt über seinen eigenen Adreßraum Sourcecode enthält Anweisungen und Variablen Compiler überträgt in Assembler bzw. Binärcode dabei Umsetzung symbolischer Namen in Adressen für bekannte Variablen wird Speicher reserviert gedachter Adreßraum beginnt zunächst bei null komplexe Programme werden oftmals getrennt übersetzt aus jeder Source-Datei wird eine Objekt-Datei erzeugt Linker: Adreßräume verknüpfen Informationen über einen Prozeß externe Referenzen zwischen Teil-Programmen auflösen jede Objekt-Datei enthält Symboltabelle mit Adressen Linker verknüpft Symboltabellen mehrere Dateien verschmilzt dabei auch die Objekt-Dateien, Bibliotheken ein gemeinsamer, durchgängiger Adreßraum entsteht Laufzeitumgebung ( Start-Programm ) wird hinzugelinkt der Adreßraum kann nun geladen werden Prozeß teilweise Auflösungen zur Laufzeit dynamisches Linken Betriebssystem benötigt diverse Verwaltungsinformationen PID (Prozeß-ID), UID (User), GID (Gruppe) Zustand, Ereignisse, auf die gewartet wird Scheduling-Daten (Basiswert, Kontostand) offene Dateien, aktuelles Verzeichnis reservierte Speicherbereiche Platz zum Sichern des Prozesskontextes,... werden in entsprechenden Datenstrukturen bereitgehalten Prozeß-Erzeugung: Verwandtschaft Prozeß-Erzeugung: Verwandtschaft ein neuer Prozeß wird erst bei Bedarf dynamisch erzeugt Kindprozeß wird aus Vater erstellt Hierarchie hierdurch weitere Prozeßzustände, z.b. created erster Prozeß wird handgearbeitet: Adreßraum, Kontext danach logische Kopie des Vaters teilen sich geöffnete Dateien u.ä. erleichtert ggf. gemeinsame Arbeit!= Windows Systemaufruf fork() erzeugt Kopie Prozeß läuft parallel zu sich Rückgabewert zeigt Identität an 0: Kindprozeß n: Vater, n ist PID des Kindes für einige Anwendungen sinnvoll sonst: exec() mit neuem Programm tauscht u.a. den Adreßraum aus
Prozeß-Erzeugung: Verwandtschaft Thread: geteilte Kontrolle im Prozeß Thread: geteilte Kontrolle im Prozeß Prozeß: verschiedene Segmente Adreßraum enthält Segmente Text, Data und Stack Text: Programmcode, feste Größe, read-only Data: Daten (z.b. Variablen), dynamische Größe Stack: dito, aber für temporäre Daten Eigenschaften Schutzmechanismen Data und Stack wachsen sich entgegen SP zeigt analog PC auf Stack-Spitze vollständiger Adreßraum Transparenz Prozeß: virtueller vs. realer Adreßraum Lage im Hauptspeicher zum Übersetzungszeitpunkt offen früher egal reale Hauptspeicheradressen nehmen virtueller Adreßraum == realer Adreßraum aber: mehrere Prozesse zeitgleich im Hauptspeicher reale Adreßräume müssen sich unterscheiden Ansatz: Relocation beim Start Offset zu allen Adressen im Prozeß addieren virtueller Adreßraum dadurch == realer Adreßraum neben Symboltabelle: Tabelle aller absoluten Adressen
Prozeß: virtuelle Speicheradressen Prozeß: virtuelle Speicheradressen nach Relocation liegt Prozeß am Stück im Hauptspeicher externe Fragmentierung schlechte Speichernutzung Frage, ob stets gesamter Prozeß-Adreßraum benötigt wird Lokalitätsprinzip: Prozesse arbeiten in kleinem Bereich daher: nur benötigte Bereiche im Hauptspeicher halten Working Set: aktuelle Bereiche der aktiven Prozesse daher: dynamische Adreßumsetzung virtuelle Adressen virtueller Adreßraum dauerhaft!= realer Adreßraum Kostenfrage Speicherhierarchie Abbildung virtuelle/reale Adresse 1. Die Adreßräume der Prozesse werden jeweils geeignet unterteilt. statische Grenzen, die nicht mehr verschoben werden jeder Teil ist entweder im Hauptspeicher oder ausgelagert 2. In welchem virtuellen Abschnitt befindet sich die Adresse? 3. Wo befindet sich dieser Abschnitt im realen Adreßraum? 4. Offset der Adresse innerhalb des Abschnitts beachten. Segmentierung: logische Teile Adreßräume der Prozesse jeweils geeignet zu unterteilen Ansatz: logisch aufteilen, z.b. anhand von Modulen dabei auch Orientierung an den Prozeß-Segmenten schlecht: jeweils unterschiedliche Größe dieser Teile keine interne, aber deutliche externe Framentierung
Segmentierung: logische Teile Paging: handhabbare Aufteilung Adreßräume der Prozesse jeweils geeignet zu unterteilen Ansatz: logisch aufteilen, z.b. anhand von Modulen dabei auch Orientierung an den Prozeß-Segmenten schlecht: jeweils unterschiedliche Größe der Teile keine interne, aber deutliche externe Framentierung zudem ist Abbildung der virtuellen Adressen umständlich Zuordnung virtuelle/reale Abschnitte Tabelle komplexe Suche für jeden einzelnen Speicherzugriff Hauptspeicher in Page Frames gleicher Größe einteilen virtuelle Adreßräume: in Pages eben dieser Größe gut: jede Page paßt in jeden beliebigen Page Frame keine externe Fragmentierung interne Fragmentierung nur in der jeweils letzten Page deutlich effizienter zu handhaben geringer Overhead Abbildung(smechanismus) für jeden Prozeß erforderlich Paging: handhabbare Aufteilung Hauptspeicher in Page Frames gleicher Größe einteilen z.b. 4096 Bytes (4K) virtuelle Adreßräume: in Pages eben dieser Größe gut: jede Page paßt in jeden beliebigen Page Frame keine externe Fragmentierung interne Fragmentierung in der jeweils letzten Page deutlich effizienter zu handhaben geringer Overhead Abbildung(smechanismus) für jeden Prozeß erforderlich Abbildung auf reale Adresse je Prozeß über Page-Tabelle virtuelle Adresse: Page + Offset (innerhalb der Page) zunächst ganzzahlige Division durch Page-Größe Abbildung via Page-Tabelle, dann Offset re-addieren durch Page-Größe 2 n sehr einfache Schaltung möglich
Paging: Page Table Entry (PTE) PTE enthält neben Zuordnung Flags zu Schutz, Referenz kein separater Speicher-Zugriff für Flags erforderlich nicht-modifizierte Seite könnte ggf. verworfen werden Page-Tabelle durch Größe der Prozesse teilweise riesig Caching in der Memory Management Unit (MMU) sonst wären Speicherzugriffe mittels Paging zu teuer Memory Management Unit (MMU) Page-Tabelle durch Größe der Prozesse teilweise riesig Caching in der Memory Management Unit (MMU) sonst wären Speicherzugriffe mittels Paging zu teuer MMU arbeitet mit Assoziativspeicher für Page-Tabelle durch Page-Tabelle werden die Adreßräume der Prozesse gegeneinander abgeschottet Schutzmechanismus Page Fault: Page nicht vorhanden Verdrängung aus dem Hauptspeicher Page bei Zugriff nicht im Hauptspeicher: Page Fault (Trap) verfügbaren Page Frame suchen, Page nachladen da selten zumeist vollständig in Software realisiert möglicherweise kein freier Page Frame Verdrängung Ziel: geeignete Page verdrängen, ggf. auf Platte sichern möglichst jene, die ohnehin nie wieder benötigt wird geht natürlich nicht, da Hellsehen noch nicht erfunden daher: Ablauf beobachten, Zukunft daraus abschätzen Lokalitätsprinzip Working-Set ermitteln und schützen