| [gesichtete Version] | [gesichtete Version] |
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 38: | Zeile 38: | ||
</p> | </p> | ||
<p> | <p> | ||
Wenn jetzt für jeden Prozess immer der gleiche Programmtext in unterschiedliche Bereiche des Hauptspeichers eingelagert werden müsste, so ergäbe sich eine Redundanz, die letztlich einer Speicherverschwendung entspricht. | Wenn jetzt für jeden Prozess immer der gleiche Programmtext in unterschiedliche Bereiche des Hauptspeichers eingelagert werden müsste, so ergäbe sich eine Redundanz, die letztlich einer vermeidbaren Speicherverschwendung entspricht. | ||
</p> | </p> | ||
</loop_area> | </loop_area> | ||
</p> | |||
<br /> | |||
<p> | |||
{{#index:DLL-Dateien|Dynamic Link Libraries|Shared Libraries}} | |||
Windows-User kennen vielleicht '''DLL-Dateien''' ('''Dynamic Link Libraries'''). Unter Unix/Linux gibt es etwas Gleichwertiges mit den sogenannten '''Shared Libraries'''. | |||
</p> | |||
<p> | |||
In beiden Fällen enthalten diese Dateien ausführbaren Code, der von vielen Prozessen genutzt wird. Wenn dieser Code nur einmal im Hauptspeicher vorgehalten werden muss, dann wird eine signifikante Einsparung von benutzem Hauptspeicher erzielt. | |||
</p> | </p> | ||
Der englische Begriff Shared Memory bedeutet übersetzt Gemeinsam genutzer Speicher. Mehrere Prozesse sollen also vom Betriebssystem die Möglichkeit zur Verfügung gestellt bekommen, dass bestimmte Speicherbereiche gemeinsam genutzt werden können.
Wer sich noch an das Kapitel Limitregister zum Speicherschutz erinnert, dem ist sicher auch noch bewußt, dass die Nutzung eines Speicherbereichs durch mehrere Prozesse eigentlich gar nicht erwünscht war, und unbedingt unterbunden werden sollte. (Was durch den Einsatz des Limitregisters ja auch realisiert wurde.)
Wenn also Shared Memory jetzt als Betriebssystemkonzept eingeführt wird, dann muss es dazu einen guten Grund geben.
Und in der Tat gibt es einen sehr guten Grund, der für den Einsatz von gemeinsam genutztem Speicher spricht:
Der (physikalische) Arbeitsspeicher ist seit jeher eine knappe Ressource. Wenn es also Möglichkeiten gibt, durch geschickte Ausnutzung von Dingen, die sowieso vorhanden sind, "gefühlt mehr RAM" zur Verfügung zu haben, dann macht es Sinn, diese Möglichkeiten auch zu nutzen.
Ein Beispiel aus der Praxis:
Wenn ein Programm gestartet, und dadurch zum Prozess wird, dann muss sein ausführbarer Maschinencode (der Programmtext) im (physikalischen) Speicher zur Verfügung stehen, damit er auf der CPU ausgeführt werden kann. (Durch die virtuelle Speicherverwaltung reicht es bekanntlich, dass nur ein Teil des Programmtextes eingelagert ist.)
Was passiert nun, wenn das gleiche Programm mehrmals gestartet wird?
Dann resultieren daraus auch mehrere Prozesse.
Wenn jetzt für jeden Prozess immer der gleiche Programmtext in unterschiedliche Bereiche des Hauptspeichers eingelagert werden müsste, so ergäbe sich eine Redundanz, die letztlich einer vermeidbaren Speicherverschwendung entspricht.
{{#index:DLL-Dateien|Dynamic Link Libraries|Shared Libraries}} Windows-User kennen vielleicht DLL-Dateien (Dynamic Link Libraries). Unter Unix/Linux gibt es etwas Gleichwertiges mit den sogenannten Shared Libraries.
In beiden Fällen enthalten diese Dateien ausführbaren Code, der von vielen Prozessen genutzt wird. Wenn dieser Code nur einmal im Hauptspeicher vorgehalten werden muss, dann wird eine signifikante Einsparung von benutzem Hauptspeicher erzielt.
Siehe Mandl 2013 Kap. 7.2.8
Diese Seite steht unter der Creative Commons Namensnennung 3.0 Unported Lizenz http://i.creativecommons.org/l/by/3.0/80x15.png