VP1 VP2 VP3 PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP1 PP4 PP6 MMU-Konfiguration für Prozess P1 Virtual Memory von P1 Physical Memory

VP1 VP2 VP3 PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP2 PP3 PP5 MMU-Konfiguration für Prozess P2 Virtual Memory von P2 Physical Memory

Pipe registrieren Kernel P2 VP1 VP2 VP3 Virtual Memory von P1 myPip … … … … p* (VP1) … … … … registerPipe(myPipe) MMU-Konfiguration für Prozess P2 PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP2 PP3 PP5

P2 Pipe(P1) P1 P2

P1 Kernel myPip … … … … p* (VP1) … … … … writeToPipe(myPipe, *data) VP1 VP2 VP3 data PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP1 PP4 PP6 Physical Memory data MMU-Konfiguration für Prozess P1

P1 Void writeToPipe(String name, byte* data) { Pipe* curPipe = getPipe(name); curPipe->write(data); } VP1 VP2 VP3 data P2 VP1 VP2 VP3 PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP1 PP4 PP6 data Aktuelle MMU-Konfiguration (P1)

PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP1 PP4 PP6 data Aktuelle MMU-Konfiguration (P1) adaptMMU(…): sucht eine leere Page, fügt einen Eintrag in die MMU ein, welcher auf den physischen Speicher der Pipe zeigt. Sie returniert einen Pointer innerhalb der neuen Page mit dem selben page- offset wie der curPipe - pointer hatte. VP4 PP2 P1 VP1 VP2 VP3 VP4 Void writeToPipe(String name, byte* data) { Pipe* curPipe = getPipe(name); int ownerPID = getOwner(name); curPipe = adaptMMU(curPipe, owner); curPipe->write(data); }

SonderFall: Pipe erstreckt sich über mehrere Pages die Pipe besteht aus einem zusammenhängenden Array Array kann sich nur über benachbarte Pages erstrecken??? Wo liegen die Read bzw. Write-Pointer (Member-Variablen)??? direkt davor? direkt danach? P2 VP1 VP2 VP3 VP4 VP5 adaptMMU muß nun alle beteiligten Pages eintragen -> wieder relativ zum neuen Basis-Pointer curPipe wie stellt adaptMMU fest auf wie vielen Pages die Pipe liegt? [pPage + length*sizeof(char) + 2*sizeof(int)] / PAGE_SIZE aufrunden ??? liegen die Member wirklich unmittelbar vor/nach dem Array?

Neuen Speicher reservieren Kernel PP4 PP5 … … [free] P1 … … PP1 PP2 PP3 P1 [free] P2 Physical Memory Table Der Kernel verwaltet eine Pyhsical Memory Table in der festgehalten wird, welche physikalischen Pages von welchen Prozessen belegt werden, bzw. welche nicht verwendet werden.

Neuen Speicher reservieren Allokiert ein Prozess neuen Speicher (new / malloc), dann wird ihm eine virtuelle Adresse geliefert, welche genug Platz innerhalb des virtuellen Speichers bietet. newlibc verwaltet den virtuellen Speicher newlibc verwendet beim allokieren virtuelle adressen in pages, die möglicherweise noch gar kein mapping zu physikalischen pages haben. PP1.1 PP2.1 PP2.2 PP1.2 PP2.3 PP1.3 MMU VP1 VP2 VP3 PP1 PP4 PP6 Aktuelle MMU-Konfiguration (P1) P1 VP1 VP2 VP3 VP4 char* pData = new char[255]; Wird in einer neuen virtuellen Page abgelegt ???

Beim ersten Zugriff auf pData, welcher in einer neuen virtuellen Page liegt, wird das auflösen durch die MMU fehlschlagen (Page-miss). Prozess benötigt neue physikalische Page void reserveNewPage(int PID, int vPage) { int physPage = getFreePage();//returniert Index einer nicht // benutzten page markPageReserved(physPage, PID);// markiert PID als besitzer von //physPage (Physical Memory Table) addMMUEntry(PID, vPage, physPage);// fügt einen Eintrag die MMU- //Tabelle von PID ein. }