Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Bs-6.51 6.6 Persistenter virtueller Speicher Idee:alle Segmente sind persistent Datei-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor.

Ähnliche Präsentationen


Präsentation zum Thema: "Bs-6.51 6.6 Persistenter virtueller Speicher Idee:alle Segmente sind persistent Datei-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor."—  Präsentation transkript:

1 bs Persistenter virtueller Speicher Idee:alle Segmente sind persistent Datei-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor.

2 bs-6.52 Segment überdauert Tod des erzeugenden Prozesses, Systemabschaltung, Systemabsturz, solange es über eine Berechtigung oder einen Namen erreichbar ist (sonst Speicherfreigabe!). Problem: Inter-Segment-Adressierung Lösung:- entweder objektbasierte Adressräume ( 6.6.1) - oder unendliche Adressräume ( 6.6.2)

3 bs Objektbasierte Adressräume (z.B. in DAS (TU Berlin ), Clouds (Georgia Tech ), Birlix (GMD Birlinghoven ), u.a.) minimale Segmentstruktur, z.B. lediglich Code, Daten, Keller Modul oder Objekt oder Code, Moduldaten, Objektdaten, Keller Objekt

4 bs-6.54 Objektidentifizierung über Berechtigung Objektaufruf/rücksprung bewirkt Wechsel des Adressraums unter Beibehaltung des Kellers, ist Mikrokern-Systemaufruf in prozedurorientierter Architektur (kein technischer Unterschied zwischen Benutzer- und Systemobjekten)

5 bs-6.55 BerechtigungenDeskriptoren für Objektefür Datensegmente für Codesegmente cx Objekt x vom Typ c

6 bs-6.56 Codesegment beginnt mit Sprungleiste: 8: 125: JUMP 0008 JUMP 0125 JUMP 4711 JUMP....

7 bs-6.57 Objektaufruf: CALL(objCap, opNo, args) ohne Code/Daten-Adressen, wohl aber Berechtigungen! Objektrücksprung: RETURN

8 ObjektX Typisches Sharing-Szenario: Prozess P Prozess Q P-Keller CodeCCodeD Q-Keller ObjektZObjektY Code Sharing Object Sharing

9 bs-6.59 Beispiele: Shared Libraries: jede Bibliothek in eigenem Adressraum Textdatei? In der Regel ineffizient – daher Aufweichung der starren Segmentierung: zusätzlich freie Datensegmente (greifbar über Berechtigungen, map/unmap ) Parameterübergabe bei CALL/RETURN kann Berechtigungen für Objekte und freie Segmente beinhalten

10 bs Unendliche Adressräume Wünschenswert: freie Inter-Segment-Adressierung ermöglichen Adressraumwechsel vermeiden Segmentkollisionen im Adressraum vermeiden Realisierung: Jedem realen Segment ist ein eigenes virtuelles Segment – für alle Prozesse! – zugeordnet.

11 bs Folgerung:unendlicher Adressraum wäre schön – hat Platz für beliebig viele Segmente, erlaubt Verzicht auf Wiederverwendung virtueller Segmente (!), die mit technischen und Sicherheitsproblemen verbunden ist. ? Was leisten 64-Bit-Adressen ? ? Braucht man 128-Bit-Adressen ?

12 bs Bit-Adressen: adressierbar sind * Bytes, Segmenterzeugung mit Rate 1000/sec à 10 6 Bytes verbraucht pro Sekunde 10 9 Adressen, Pro Tag ( sec ) werden damit weniger als Adressen verbraucht, 16*10 18 / = 16*10 4 Adressen reichen für mindestens Tage. ! Für netzweite Adressräume verteilter Systeme wurden sogar schon 128-Bit-Adressen realisiert (MONADS, Univ. of Newcastle, Australien, )

13 bs Typische Charakteristika unendlicher Adressräume: Berechtigungen für Segmente, map/unmap Seitentabellen auslagerbar (Seitentabelle entspricht file map im Dateideskriptor!) integrierte Speicherbereinigung (für realen Speicher!)

14 bs Beispiel MONADS Hardware: 128-Bit-Adressraum mit Paging Segmente* nicht an Seitengrenzen gebunden Capability-Register für capability-basierte Adressierung: baselengthrights R,W,X * haben festes Format (control, capabilities, regular data)

15 bs MONADS Software (Newcastle, Bremen, Ulm [Keedy et al.]) realisiert damit objektbasierten, persistenten Adressraum: Module Capability: module handlerights meta-rights kein map – wegen capability-basierter Adressierung: jeder Prozess hat gleichen Adressraum mit allen existierenden Segmenten – kann aber nur diejenigen Segmente ansprechen, für die er Berechtigungen hat. (Berechtigung in Register laden map )

16 bs Stabiler Speicher (stable storage) = durch Systemsoftware realisierter virtual storage mit der Eigenschaft, sogar Hardware- und System- zusammenbrüche unbeschadet zu überstehen – im Gegensatz zum flüchtigen Speicher (volatile storage), dem Arbeitsspeicher; wird (natürlich) mit Hilfe des externen Speichers realisiert. Voraussetzung: keine Plattenschäden (andernfalls Platten duplizieren (spiegeln))

17 bs Grundprinzipien: regelmäßige Sicherungs-Operation hinterlässt Platten in konsistentem Zustand (s.u.). Nach Sicherung geänderte Seiten werden beim Verdrängen auf neu bereitgestellte Platten-Sektoren hinauskopiert (shadow pages); Seitentabelle wird entsprechend geändert – und selbst entsprechend gesichert (da selbst im virtuellen Speicher!). Erste Seite der Seitentabelle und ihre shadow page werden im Arbeitsspeicher gehalten.

18 bs Sicherungs-Operation: Die erste Seite der Seitentabelle wird durch ihre shadow page ersetzt – im Arbeitsspeicher und auf der Platte.

19 bs Sicherungs-Operation: Die erste Seite der Seitentabelle wird durch ihre shadow page ersetzt – im Arbeitsspeicher und auf der Platte. shadow pages

20 bs Aktuell ist die gesicherte Version unter der Voraussetzung, daß eine geänderte Seite möglichst bald verdrängt wird. Korrekt ist dieses Verfahren unter der Voraussetzung, daß das Schreiben eines Blocks auf die Platte ein hardwaremäßig atomarer Vorgang ist.

21 bs Aktuell ist die gesicherte Version unter der Voraussetzung, daß eine geänderte Seite möglichst bald verdrängt wird. Korrekt ist dieses Verfahren unter der Voraussetzung, daß das Schreiben eines Blocks auf die Platte ein hardwaremäßig atomarer Vorgang ist. Falls nicht: 2 vergangene Versionen auf Platte halten – von denen die ältere garantiert konsistent ist: Versionierte Wurzelseiten: n-1 n bedeutet: wurde nicht vollständig geschrieben!


Herunterladen ppt "Bs-6.51 6.6 Persistenter virtueller Speicher Idee:alle Segmente sind persistent Datei-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor."

Ähnliche Präsentationen


Google-Anzeigen