Makro | Kurzbeschreibung |
CSTAT | ändert den Status von Speicherseiten eines Programms (Seitenwechsel und Lese-/Schreibzugriff) |
CSTMP | ändert den Lese-/Schreibstatus auf einen Memory Pool |
DISMP | beendet die Teilnahme an einem Memory Pool. Der Memory Pool wird aufgelöst, wenn das aufrufende Programm der letzte (einzige) Teilnehmer ist |
ENAMP | richtet einen Memory Pool ein oder ermöglicht die Teilnahme an einem bestehenden Memory Pool |
MINF | informiert über Seitenbelegung und Größe eines Memory Pools |
RELMP | gibt (zusammenhängenden) Speicherplatz eines Memory Pools frei |
REQMP | fordert (zusammenhängenden) Speicherplatz für einen Memory Pool an |
SHOWMP | informiert über Common Memory Pools, die aktuell im System angelegt sind |
Eigenschaften eines Memory Pools
Ein Memory Pool ist ein zusammenhängender Speicherbereich im Klasse-6-Speicher, der von mehreren Anwendern gemeinsam benutzt werden kann. Jeder Pool-Teilnehmer darf in jeder Seite des Memory Pools lesen oder schreiben. Ein Anwender, der kein Teilnehmer ist, hat keinen Zugriff auf die Pool-Seiten.
Wenn ein Pool-Teilnehmer den Inhalt oder den Status der Pool-Seiten ändert, sind alle Pool-Teilnehmer davon betroffen. Schreibt ein Teilnehmer in eine Seite des Pools, so sind diese Daten allen anderen Teilnehmern zugänglich. Schützt ein Teilnehmer eine Pool-Seite gegen Überschreiben (Makro CSTAT), so kann kein Pool-Teilnehmer mehr in diese Seite schreiben. Unterprogramme, die im Pool liegen, sollen ablaufinvariant sein.
Um die Zugriffe auf den Memory Pool zu koordinieren und eine sinnvolle Zusammenarbeit zu sichern, sollten die teilnehmenden Tasks synchronisiert ablaufen.
Dafür steht dem Benutzer z.B. das Verfahren der (Task-)Serialisierung zur Verfügung (siehe "(Task-)Serialisierung").
Informationen über die aktuell im System angelegten Memory Pools und die jeweils angeschlossenen Tasks liefert der Makro SHOWMP und das BS2000-Kommando /SHOW-MEMORY-POOL-STATUS, siehe Handbuch „Kommandos“ [19].
Eröffnen eines Memory Pools
Mit dem Makroaufruf ENAMP kann ein Anwender einen Memory Pool einrichten oder sich einem bestehenden Memory Pool anschließen.
Richtet ein Anwender den Pool ein, so legt er dabei dessen Namen, Geltungsbereich und Größe für alle weiteren Teilnehmer verbindlich fest. Vom Geltungsbereich hängt es ab, ob und welche Tasks noch an dem Pool teilnehmen können.
Die Pool-Größe ist begrenzt durch den verfügbaren Benutzerspeicher der Teilnehmer. Der Memory Pool wird in 64 KByte- oder 1 MByte-Einheiten angelegt. Memory Pools aus 64 KByte-Einheiten werden immer unterhalb der 16 MByte-Grenze angelegt und langfristig nicht unterstützt. Es wird empfohlen, nur Memory Pools aus 1 MByte-Einheiten anzulegen (bessere Performance). Der ENAMP-Aufruf bewirkt, dass das System die entsprechende Anzahl von Einträgen in der Segmenttabelle für den Pool reserviert (siehe Bild 6).
Schließt sich ein Anwender einem bestehenden Memory Pool an, so muss er dessen Namen, Geltungsbereich und Größe akzeptieren. An Stelle des Namens stellt das System eine Kurzkennung zur Verfügung, die die Verarbeitung beschleunigt. Jeder Teilnehmer kann bei der Pool-Eröffnung eine Adresse angeben, an der ihm das System die Kurzkennung einträgt.
Bei der Eröffnung kann jeder Anwender individuell festlegen, welcher Teil seines verfügbaren Adressraums dem Memory Pool zugeordnet sein soll. Er gibt für den Memory Pool eine Anfangsadresse an, die in seinem Adressraum liegt. Jeder Teilnehmer kann den Pool mit dem selbstgewählten Bereich seines Adressraums adressieren. Die Adresse muss nicht einheitlich von allen Teilnehmern gewählt werden. Das System übergibt den Teilnehmern die virtuelle Adresse des ersten Pool-Byte in Register R1.
Schließen eines Memory Pools
Mit dem Makroaufruf DISMP wird die Teilnahme an dem angegebenen Memory Pool beendet. Der Teilnehmer kann danach wieder über den Teil seines Adressraums, der dem Pool zugeordnet war, neu verfügen. Der Memory Pool wird aufgelöst, wenn der Aufrufer von DISMP der letzte oder einzige Pool-Teilnehmer war. (Der den Memory Pool auflösende Teilnehmer muss nicht derjenige sein, der den Memory Pool eingerichtet hat).
Speicheranforderung im Memory Pool
Mit dem Makroaufruf REQMP kann ein Pool-Teilnehmer seitenweise (4 KByte) Speicherplatz für einen Memory Pool anfordern. Das System belegt die angeforderten Seiten in dem Bereich des virtuellen Speichers, der für den Pool (durch ENAMP) reserviert ist.
In den belegten Seiten kann nun jeder Pool-Teilnehmer schreiben und lesen. Der Teilnehmer, der die Belegung (verbindlich für alle) vornimmt, legt fest, welche und wie viele Seiten im reservierten Pool-Bereich belegt werden. Der Makro MINF informiert über Seitenbelegung und Größe des Memory Pools.
Speicherfreigabe im Memory Pool
Jeder Teilnehmer an einem Memory Pool kann mit den Makroaufruf RELMP seitenweise Speicher freigeben, der für den Memory Pool belegt war. Dabei spielt es keine Rolle, welcher der Teilnehmer den Speicher belegt hatte, und in welchen Portionen er belegt worden war. Der Aufrufer von RELMP legt fest, wie viele und welche der belegten Seiten freigegeben werden. Diese Freigabe gilt für alle Pool-Teilnehmer.
Seitenstatus im Memory Pool
Im Makro ENAMP kann festgelegt werden, ob der Speicherbereich resident sein soll. Der Aufrufer muss jedoch dazu berechtigt sein: Im Kommando START-EXECUTABLE-PROGRAM für das Programm, das den ENAMP aufruft, muss vereinbart werden, wie viele Seiten des Prozesses resident sein dürfen. Diese Angabe muss der Benutzer berücksichtigen, wenn er im ENAMP-Aufruf die Größe des Memory Pools festlegt und gleichzeitig angibt, dass der Pool resident sein soll.
Mit dem Makroaufruf CSTAT kann ein Pool-Teilnehmer den Seitenstatus im Benutzerspeicher ändern. Der Seitenstatus eines Memory Pools kann mit dem Makro CSTAT nur von seitenwechselbar zu resident geändert werden. Eine Änderung des Seitenstatus von resident zu seitenwechselbar wird bei Memory Pools ignoriert, die über ENAMP resident festgelegt worden sind.
Der Makro CSTAT berücksichtigt keine Memory-Pool-Grenzen. Der Seitenbereich, der mit CSTAT beeinflusst wird, darf außerhalb eines Pools beginnen und im Pool enden und umgekehrt. Bei einer Änderung des Seitenstatus von resident zu seitenwechselbar werden nur die Seiten geändert, die außerhalb des residenten Memory Pools liegen.
Wird der Seitenstatus von seitenwechselbar zu resident geändert, so können alle Pool-Teilnehmer auch auf die residenten Seiten zugreifen. Diese Statusänderung kann jedoch nur von einem Pool-Teilnehmer durchgeführt werden, der dazu berechtigt ist.
(Im START-EXECUTABLE-PROGRAM-Kommando für das Programm, das CSTAT aufruft, ist festgelegt, ob und wie viele Speicherseiten resident sein dürfen.)
Der Anwender kann mit CSTAT auch die Zugriffsart (Lese-/Schreibzugriff) auf die angegebenen Speicherseiten festlegen. Die Speicherseiten können sowohl in einem Memory Pool als auch außerhalb desselben liegen.
Mit dem Makro CSTMP kann der (dazu berechtigte) Anwender die Zugriffsart für einen Memory Pool festlegen. Die Angabe betrifft immer alle Speicherseiten des Memory Pools. Folgendes ist zu beachten:
Bezüglich der Änderung der Zugriffsart (Lese-/Schreibzugriff) hat CSTAT eine niedrigere Priorität als CSTMP.
Mit CSTMP eingerichteter Schreibschutz kann mit CSTAT nicht aufgehoben werden.CSTAT wird abgewiesen, wenn der Schreibschutz mit CSTMP eingerichtet wurde.
Mit CSTAT eingerichteter Schreibschutz kann mit CSTMP auf alle Pool-Seiten erweitert werden.
Einschränkungen bei Verwendung von Memory Pools
Fixpunktverarbeitung (Makro WRCPT/Kommando RESTART-PROGRAM) ist nicht zugelassen, wenn ein Memory Pool eröffnet ist.
Das HOLD-TASK-Kommando (siehe Handbuch „Kommandos“ [19]) wird abgewiesen.
Wenn ein nicht behebbarer Hauptspeicherfehler in einer Pool-Seite auftritt, wird dasjenige Programm beendet, das auf die fehlerhafte Speicherseite zugreift.
Bild 6: Anschlussrealisierung und Zugriff auf eine Memory-Pool-Seite (/390-Server)
(1) | Mit dem Makro ENAMP erfolgt der Anschluss an den Memory Pool AB. |
(2) | In den nächsten freien Eintrag der Segmenttabelle wird die reale Anfangsadresse der Memory-Pool-Seitentabelle eingetragen. In diesem Fall ist der nächste freie Eintrag der Eintrag für das 3. Segment. Für Anwender 1 beginnt also der Memory Pool AB an der virtuellen Adresse X'00200000'. Diese virtuelle Anfangsadresse wird im Register R1 abgespeichert. |
(3) | Der Inhalt von Register R1 wird in Register R5 geladen. Beide Register enthalten nun die virtuelle Anfangsadresse des Memory Pools AB für den Anwender 1. |
(4) | Zur virtuellen Anfangsadresse des Memory Pools AB werden 5 Seiten (X'5000') addiert und das Ergebnis in Register R5 abgelegt. |
(5) | Mit dem REQMP-Makro wird nun diese 6. Seite des Memory Pools AB angefordert. |
(6) | Der 6. Eintrag in der Memory-Pool-Seitentabelle enthält die reale Frame-Nummer der 6. Seite des Memory Pools AB im Hauptspeicher. Der 6. Eintrag in der Seitentabellen-Erweiterung enthält die logische Block-Nummer der 6. Seite im Seitenspeicher. |
(7) | Zugriff auf die 6. Seite des Memory Pools AB. |