---

Hintergrund: Speicherschutz und virtueller Speicher (von M. Christoph)

Nachdem der letzte Bericht wenig Reaktionen hervorgerufen hat, bis auf die Handvoll PPC-Fanatiker, kann das Thema mit dieser Aufgabe noch weiter vertieft werden.

Zuerst muß ich meine Aussage bezüglich MorphOS korrigieren, wie mir Ralph Schmidt mitteilte. Die angebotene Möglichkeit auf Klarstellung hat er jedoch unbeantwortet gelassen und somit seine Chance auf die Richtigstellung verspielt. Und ich werde mich hüten, einen zweiten Versuch zu unternehmen, was und wofür MorphOS nun ist.

Bezüglich des Megahertz-Werts sei noch anzumerken, daß zwar Motorola-Chips (68k und PPC) eine stärker optimierte interne Befehlsverarbeitung aufweisen und daher mit weniger MHz auskommen, als ihre Konkurrenten. Diese weisen aber heute ein Vielfaches der MHz auf, wodurch sie eben mehr Rechenleistung an den Tag legen können. Und auch ein 2GHz-PPC, der nur in den Labors existiert, wird daran nichts ändern, da auch Intel/AMD nicht stehenbleiben. Der Marktanteil an Motorola-Chips ist trotz des breiten Einsatz in Industrie und Zubehörgeräten verschwindend gering - unter 10%! Desweiteren würde ich ihn persönlich auch als rückläufig einstufen. Als Beispiel seien Drucker und Modems angeführt, die immer weniger Eigenintelligenz aufweisen und statt dessen immer mehr vom PC (und dessen Intel-Prozessor) vorarbeiten lassen.

Im Massenmarkt entscheidet eben der Preis und nicht die Leistung...


Warum Speicherschutz nie hundertprozentig funktionieren kann:


Daß ein Windows NT/XP, aber auch das stabilste Betriebssystem der Welt, Linux, durch Unachtsamkeit oder auch mutwillig zum Absturz gebracht werden kann, zeigt, daß es keinen hundertprozentigen Speicherschutz geben kann. Alles was Speicherschutz tatsächlich zu leisten imstande ist, ist das Betriebssystem am Laufen zu halten, wenn ein Anwendungsprogramm einen Fehler verursacht. Zu einem Verlust von unmittelbar vor einem Programmabsturz bearbeiteten Daten kann es jedoch trotzdem kommen, sofern die betreffende Software nicht über eine automatische "Notfall-Sicherungs- Funktion" verfügt.

Die ideale Lösung wäre daher ein "Zwischending". Auf der einen Seite das Betriebssystem so abzuschotten, daß ihm kein Programm "schaden" kann. Auf der anderen Seite die Daten des Anwendungsprogramms auf Festplatte cachen, damit beim Crash eine möglichst aktuelle Version der Daten zur Verfügung steht.

Wird ein Programm in den Speicher geladen, so bekommt es vom Betriebssystem einen speziell reservierten Bereich zugewiesen. Das Programm kann nicht außerhalb dieses Bereichs zugreifen, und ein anderes Programm kann nicht innerhalb zugreifen. Sollen jetzt Nachrichten ausgetauscht werden (was ständig notwendig ist), so wird der Wunsch an das Betriebssystem geschickt. Dieses reserviert für den Empfänger einen Speicherbereich, kopiert die Nachricht um und leitet es dem Zielprogramm zu usw. Dadurch wird verhindert, daß ein Programm im Speicher eines anderen "wühlt". Daß das Ganze natürlich seine Zeit braucht (und Speicheroperationen brauchen relativ viel Zeit), sollte damit jedem klar sein. Mit mehr Megahertz und schnelleren RAM-Bausteinen reduziert sich natürlich der Zeitaufwand. Trotzdem wird oft die volle Performance benötigt. Hierfür gibt es dann einen speziellen Speicherbereich, 'shared memory' genannt. Dieser kann von mehreren Programmen angesprochen werden. In diesem Fall sind aber spezielle Vorkehrungen notwendig, damit nicht zwei Programme gleichzeitig eine Nachricht dort ablegen. Und ganz egal ob shared oder single memory verwendet wird, können immer noch "undefinierte" Parameter in den Nachrichten zu Problemen im Zielprogramm führen - je nach Toleranz und Berücksichtigung des Programmierers.

Und dann gibt es noch die Gruppe der Hardwaretreiber. Diese arbeiten schon aufgrund der Performance ohne Speicherschutz! Und genau das ist der Schwachpunkt, unter dem aktuell auch Windows XP stark leidet. Werden nämlich ältere Treiber unter XP verwendet, so reagieren diese oft nicht wie gewünscht, sondern verhalten sich "unberechenbar". Das trifft prinzipiell auch auf Linux zu, wobei aber dort das Betriebssystem trotzdem noch besser abgeschirmt ist und eher mit "virtuellem Speicher" bzw. Speicherknappheit zu kämpfen hat.

Wer also unter diesen Gesichtspunkten Speicherschutz verlangt, damit das neue Betriebssystem nicht mehr abstürzt, wird enttäuscht werden. Und nur weil es andere brauchen, um amoklaufende Programme in Schach zu halten, kann auch ein modernes Betriebssystem noch ohne Speicherschutz auskommen. Aber es ist eben ein "gutes" Verkaufsargument.

Wie auch immer sich die Entwickler von OS 4.0 entscheiden, muß es ein eindeutiges für oder wider sein, aber kein "wird vorgesehen". AmigaOS hat bereits mit der Version 2.0 vorgesehen, unixartige Dateirechte einzuführen. Die entsprechenden Bits sind zwar seit Jahren vorhanden, aber bis heute nicht in Benutzung. Auch Datei- und Verzeichnislinks wurden gleichzeitig eingeführt. Erst die vielen Fehlerkorrekturen in OS 3.5/3.9 machten die Benutzung von Links möglich - und trotzdem werden sie nur halbherzig und nicht an allen Stellen unterstützt. Im Klartext heißt das für den Anwender, daß Links nicht verwendet werden können. Und Speicherschutz setzt genauso tief im System an. Eine halbherzige Einbindung ist deshalb gleichzusetzen mit "wird niemals richtig funktionieren".


Warum virtueller Speicher auch kein Allheilmittel ist:


Betrachtet man so manches Linux- (oder Unix- im allgemeinen) Programm, so stellen sich dem Amiga-Programmierer oftmals die Haare zu Berge. Es werden fortlaufend Dateihandles reserviert, die nie freigegeben werden, es wird Speicher ohne Ende angefordert und nicht einmal überprüft, ob es funktioniert hat. Schließlich kümmert sich ja das Betriebssystem darum, daß Speicher ausgelagert und dem Programm ein neuer Speicherbereich bereitgestellt wird. Und Linux soll sich am Programmende auch gefälligst darum kümmern, daß wieder alle Ressourcen freigegeben werden. Diese Verschwendung an Ressourcen zeigt sich auch deutlich bei "Direktportierungen" wie z.B. mySQL oder Apache. Würden Amiga-Programmierer auch so arbeiten, würden heutige Programme und einfache Tools nicht mehr auf "alten" (nicht aufgerüsteten) Amigas laufen.

Ein abschreckendes Beispiel auf dem Amiga ist ArtEffect: Es verbraucht Speicher ohne Ende und lagert zusätzlich noch ständig Daten aus. Und das auch wenn nur ein "kleines" Bild geladen wird. Da stellt sich mir die Frage, ob dort nur bewiesen werden soll, daß es nicht mehr ohne virtuellen Speicher geht.

Virtueller Speicher ist somit mit Sorgfalt einzusetzen. Die notwendige Intelligenz bei den Programmierern ist allerdings oft anzuzweifeln. Dies führt im Endeffekt lediglich zu langsameren Programmen, da jeder Speicher "ohne Rücksicht" reserviert und das Betriebssystem ständig aus- und einlagern muß, was auch seine Zeit benötigt, und natürlich Platz auf der Festplatte.

Linux-Programmierer zeigen dabei häufig auch die Unsitte, daß virtueller Speicher ohne Ende zur Verfügung steht - so zumindest die Programmierphilosophie.

Aber eine einfache Unachtsamkeit des Programmierers (z.B. mit einer rekursiven Funktion) oder des Anwenders (z.B. viele große Grafiken in das Malprogramm laden) können dazu führen, daß sowohl Hauptspeicher, als auch der virtuelle Speicher auf der Festplatte nicht mehr ausreichen. Und dann? Dann bleibt sogar ein Linux einfach stehen oder läuft Amok. Ein vernünftiges Amiga-Programm hingegen meldet "zuwenig freien Speicher" und verweigert die Operation oder startet nicht. Durch Beenden anderer Programme kann dabei genug Speicher freigegeben werden, um das andere Programm erneut zu starten. Und reserviert nicht jemand die letzten 100 Byte des Chip-RAMs, läuft auch das Amiga-Betriebssystem und die Workbench absolut stabil weiter.

Nicht vergessen werden sollte auch, aus welcher Zeit und aus welchem Grund es virtuellen Speicher gibt. "Damals", als Speicherbausteine noch teuer waren und Rechner mit 16 MByte auskommen mußten, war virtueller Speicher die Lösung, um übergroße Grafiken und Dokumente be- und verarbeiten zu können. Heutzutage, wo Rechner schon mit 256 MByte und mehr ausgeliefert werden, hat virtueller Speicher keine Bedeutung mehr und sollte deshalb auch nicht überbewertet werden.

Betrachtet man allerdings die Größe so mancher Windows-Programme, stellt sich mir unweigerlich die Frage, ob dort nach "Kilogramm" abgerechnet wird? Ohne Zuwachs an sichtbaren Funktionen werden die Programme immer größer und größer. Oder soll hier nur der Speicherbaustein-Industrie unter die Arme gegriffen werden?

Damit soll es für heute genug der technischen Worte sein.

Michael Christoph