Bs-6.51 6.5 Dateien als Segmente Idee:Datei = persistentes Segment Konsequenzen:  Datei kann in virtuellen Adressraum eingeblendet werden (memory-mapped.

Präsentation zum Thema: "Bs-6.51 6.5 Dateien als Segmente Idee:Datei = persistentes Segment Konsequenzen:  Datei kann in virtuellen Adressraum eingeblendet werden (memory-mapped."—  Präsentation transkript:

1 bs-6.51 6.5 Dateien als Segmente Idee:Datei = persistentes Segment Konsequenzen:  Datei kann in virtuellen Adressraum eingeblendet werden (memory-mapped file)  keine spezielle Ein/Ausgabe für Dateien, kein Blockpuffer Geschichte:reicht zurück bis MULTICS (M.I.T. 1965-70)

2 bs-6.52 6.5.1 Programmladen über Seitenfehler (demand-paged program loading) Code-Teil der Programmdatei wird wie Code-Segment im Sekundärspeicher behandelt: exec richtet Segmentstruktur des Prozesses ein (wie üblich), überträgt aber keinen Code in den Primär- oder Sekundärspeicher. In Unix erstmalig mit Version System V, heute bei den meisten Betriebssystemen üblich.

3 bs-6.53 Ablauf: 1. exec : Segmente des Prozesses einrichten (gemäß Beschreibung in Programmdatei) : Datei aktivieren: reqDesc liefert dno dno im Deskriptor des Code-Segments notieren (für Nicht-Code-Segmente ist dieses Feld 0) Seitendeskriptoren einrichten: - spezielle Markierung „von Datei einlagern“ - Blocknummer innerhalb der Datei 2.Ausgezeichnete Startseite einlagern und starten 3. Bei Bedarf – gesteuert durch Seitenfehler – Rahmen für einzelne Seite finden und Codeseite einlagern 4. Verdrängen erfolgt ohne physisches Kopieren

4 bs-6.54 6.5.2 Dynamisches Binden (dynamic link libraries, DLLs, shared libraries) Varianten für das Einbinden von vorübersetzten Prozeduren, Modulen, Klassen etc. aus Bibliotheken:  statisch: nach der Übersetzung, vor dem Laden;  zur Ladezeit gemäß Angaben in Programmdatei: entsprechende Segmente einrichten bzw. mitbenutzen;  zur Laufzeit bei Bedarf – „dynamisch“.

5 bs-6.55  Binder (linker, linkage editor) entnimmt Code aus Bibliothek und fügt ihn mit dem anderen Code zusammen (mit Adressverschiebung und Auflösung externer Bezugnahmen); kein Sharing!  Bindender Lader (linking loader) bindet beim Laden und berücksichtigt dabei Codesegmente, die bereits von anderen Prozessen benutzt werden (  Sharing); Achtung:Adressierungsproblem, wenn nicht jeder Code einem bestimmten (virtuellen) Segment zugeordnet ist! Das tatsächliche Laden der Codesegmente erfolgt seitenweise bedarfsgesteuert, wie in 6.5.1 skizziert, also nicht durch den Lader.

6 bs-6.56  Vertreterroutinen (stubs) für externe Prozeduren werden statisch eingebunden; sie veranlassen beim jeweils ersten Aufruf Segmenterzeugung bzw. -anbindung sowie entsprechende Aufrufumlenkung; die Bereitstellung des Codesegments erfolgt durch einen speziellen Systemaufruf (  6.5.3).

7 bs-6.57 6.5.3 Einblenden beliebiger Dateien (memory-mapped files)  mittels geeigneter Systemaufrufe  erübrigt Blockpuffer (und damit Kopiervorgang!)  erübrigt Systemaufrufe read, write, seek  erübrigt eigenen Mechanismus für dynamisches Binden  erübrigt eigenen Mechanismus für Sharing (5.4.3  )5.4.3

8 bs-6.58 6.5.3.1... ohne Capabilities addr = open(name,mode) (Segment/Datei einblenden) etabliert die Datei als Segment (falls nicht schon geschehen), d.h. richtet Segmentdeskriptor und Seitentabelle ein; blendet das Segment an geeigneter Stelle in den Adressraum ein und liefert die Adresse der ersten Zelle. Danach z.B. x = addr[0]; Zugriff auf erste Zelle... x = addr[37];... close(addr); Segment wird ausgeblendet, ggfls. in Datei zurückkopiert

9 bs-6.59 Beispiel Kopieren einer Datei: cp src dst... from = open(src, READING); stat(src,attr); length1 = attr.st_size; to = open(dst,WRITING); stat(dst,attr); length2 = attr.st_size; if(length2 == 0) for(int i=0; i<length1; i++) to[i] = from[i]; close(from); close(to);

10 bs-6.510 Bemerkungen:  read, write, seek als einfache Bibliotheksroutinen  Semantik eines weiteren open ? (Datei über 2 virtuelle Segmente erreichbar??)  Ausnutzung in höheren Programmiersprachen: benutzerdefinierte Dateitypen möglich – und damit persistente Objekte.

11 bs-6.511 6.5.3.2... mit Capabilities cap = lookup(name,mode) * etabliert die Datei als Segment (falls nicht schon geschehen), d.h. richtet Segmentdeskriptor und Seitentabelle ein, und liefert eine Berechtigung für dieses Segment (vgl. 6.5.3.1  ).6.5.3.1

12 bs-6.512 addr = map(cap) blendet das mit cap identifizierte Segment an geeigneter Stelle in den Adressraum ein und liefert die Adresse der ersten Zelle (vgl. 6.5.3.1  ).6.5.3.1 unmap(addr) blendet das Segment wieder aus

13 bs-6.513 Ähnlich in POSIX, Solaris, Linux,...: fildes = open(...); normales Öffnen einer Datei, fildes  Berechtigung a = mmap(addr,length,prot,flags,fildes,offset) blendet Datei in den Adressraum ein und liefert Adresse der ersten Zelle *. prot ist NONE oder Kombination von R,W,X. flags erlaubt u.a. SHARED, PRIVATE (private Kopie) munmap(a,length) blendet wieder aus (bis length )

14 bs-6.514 6.5.3.3... und in Windows  Dateien sind – wie bei POSIX – sowohl normal als auch als memory-mapped files benutzbar  Berechtigungen für „File-Mapping-Objekte“ (  Segmente) kommen zum Einsatz  DLLs werden über diesen Mechanismus realisiert  Gemeinsame Segmente sind nur über diesen Mechanismus möglich

15 bs-6.515  fHandle = OpenFile(name,access,...) liefert open file handle  fmHandle = CreateFileMapping( fHandle, wenn –1, Segment ohne Datei... name) Segmentname liefert Berechtigung für Segment Für Sharing: statt Weitergabe des fmHandle auch fmHandle = OpenFileMapping(...,name)

16 bs-6.516  addr = MapViewOfFile(fmHandle,...) blendet das Segment an geeigneter Stelle ein und liefert Adresse der ersten Zelle. ODER mit explizitem Adressenwunsch: addr = MapViewOfFileEx(fmHandle,..., address)  x = addr[0]; usw.

17 bs-6.517  UnmapViewOfFile(addr) Ausblenden des Segments  CloseHandle(fmHandle) Berechtigung für Segment aufgeben  CloseHandle(fHandle) Berechtigung für Dateiobjekt aufgeben