Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Synchronisation und Serialisierung

&pagelevel(3)&pagelevel

Der Basismechanismus für Synchronisation und Serialisierung in einem XCS-Verbund sind DLM-Locks, wobei ein Lock aus Sicht des DLM durch einen Namen und einen (rechner- oder verbundweiten) Geltungsbereich identifiziert ist. Die Zuordnung zwischen zu sperrendem Betriebsmittel (z.B. Gerät, Block einer Datei) und einem Namen liegt in der Verantwortung des Benutzers, ebenso die Aufgabe, für die XCS-weite Eindeutigkeit des Namens zu sorgen.
Eine Lock-Anforderung kann synchron oder asynchron gestellt werden. Deadlocks werden mithilfe von Timern erkannt.

Der Lock-Modus spezifiziert die Zugriffsrechte des Lockhalters. Insgesamt sechs Lock-Modi werden unterstützt:

  • Null mode
    Der Halter dieses Locks darf auf die zugeordnete Ressource nicht zugreifen; alle anderen Lock-Anforderungen sind mit diesem Modus verträglich.

  • Concurrent read mode
    Der Halter dieses Locks ist berechtigt, die zugeordnete Ressource zu lesen, muss aber berücksichtigen, dass andere Leser oder Schreiber zur selben Zeit auf die Ressource zugreifen können.

  • Concurrent write mode
    Der Halter dieses Locks darf die zugeordnete Ressource ändern, muss aber berücksichtigen, dass andere Leser oder Schreiber zur selben Zeit auf die Ressource zugreifen können.

  • Protected read mode
    Der Halter dieses Locks ist berechtigt, die zugeordnete Ressource zu lesen. Zur selben Zeit darf keine andere Task die Ressource ändern.

  • Protected write mode
    Der Halter dieses Locks ist berechtigt, die zugeordnete Ressource zu ändern. Zur selben Zeit darf keine andere Task die Ressource ändern, wohl aber im concurrent read mode lesen.

  • Exclusive mode
    Ausschließlich der Halter dieses Locks hat Zugriff auf die Ressource. Zur selben Zeit darf eine andere Task die Ressource weder ändern noch lesen.

Welcher Lock-Modus zu wählen ist, hängt letztlich davon ab, in welchem Maß eine Ressource geschützt werden muss, um einen Verarbeitungsschritt ausführen zu können.

Optional ist zu jedem Lock ein Speicherbereich (der sog. „Lock Value Block“) verfügbar, mit dessen Hilfe die Lock-Halter Daten austauschen können. Der Inhalt des Lock Value Blocks kann von Inhabern eines Schreib-Locks verändert und von Inhabern eines Lese-Locks gelesen werden. Der Lock Value Block kann in diesem Sinn als rechnerübergreifender verteilter Speicher angesehen werden.

Fällt ein einem XCS-Verbund angehörender Rechner aus oder wird auf dem Rechner MSCF beendet, so wird im Rahmen der erforderlichen Rekonfigurationsmaßnahmen eine Recovery für die auf diesem Rechner gehaltenen Locks durchgeführt. Bei einer Task-Beendigung erfolgt eine Lock-Recovery innerhalb der im Rahmen der Task-Beendigung durchzuführenden Verarbeitungsschritte.

Die globalen DLM-Locks werden von einer HIPLEX-MSCF-Anwendung verwaltet. Die Verfügbarkeit der globalen DLM-Locks auf einem XCS-fähigen Rechner setzt somit die Existenz einer MSCF-Session voraus. Sinnvollerweise sollten mit globalen DLM-Locks nur solche Ressourcen geschützt werden, deren Verfügbarkeit ebenfalls an eine MSCF-Session gebunden ist.

Die Schnittstellen des DLM werden durch zwei DSSM-Subsysteme realisiert. Das Subsystem DLMUSER ist für die Lock-Behandlung innerhalb eines Rechners zuständig und nimmt die Aufträge über die Benutzerschnittstelle entgegen. Für die rechnerübergreifende Lock-Behandlung werden die Aufträge, falls erforderlich, von DLMUSER an ein zweites DSSM-Subsystem, den Node Synchronisation Manager (NSM), weitergereicht. Vom XCM gesteuert führt der NSM neben der rechnerübergreifenden Lock-Behandlung auch Lockbezogene Rekonfigurationen durch. Der NSM ist also eine beim XCM angemeldete Rekonfigurationseinheit, eine „registrierte Funktion“.

Eine detaillierte Darstellung des DLM enthält das Handbuch „Makroaufrufe an den Ablaufteil“ [12].

Beispiele

  • Partnerüberwachung
    In einem XCS-Verbund lässt sich jeder Rechner einen exklusiven Lock zuteilen. Das „gesperrte“ Betriebsmittel ist in diesem Fall der Rechner selbst, der Lock-Name z.B. der eindeutige Rechnername. Versuchen nun die anderen dem XCS-Verbund angehörenden Rechner, diesen Lock exklusiv zu erhalten, so können sie davon ausgehen, dass der den Lock haltende (also der zu überwachende) Rechner aktiv ist, solange sie den Lock nicht exklusiv erhalten bzw. über eine eingetretene Änderung informiert werden. Die Ursache hierfür ist, dass bei einem Absturz des zu überwachenden Rechners DLM den Lock freigibt und einem anderen Rechner exklusiv zuordnet. Der Rechner, der den exklusiven Lock erhalten hat, kann die Aufgaben des abgestürzten Rechners übernehmen.

    Der Rechner, der den exklusiven Lock des Partners erhält, kann die zwischen den Rechnern gemeinschaftlich abzuwickelnden Aufgaben übernehmen. Die Zuteilung des Partner-Locks bedeutet jedoch nicht zwangsläufig, dass der Partner ausgefallen ist, sondern nur, dass er seine Mehrrechnerfähigkeit verloren hat. In diesem Fall können die anderen Rechner über die Shared Ressourcen des Partners verfügen.
    Dieser Mechanismus darf nicht zur Umschaltung und Benutzung von exklusiv zugeordneten Ressourcen (z.B. exklusiv importierte Pubsets) verwendet werden, da bei einem Kommunikationsfehler mit nachfolgendem Entladen von MSCF diese Betriebsmittel zerstört werden können.

  • Synchronisation von Dateizugriffen
    Auf PAM-Dateien kann von mehreren Rechnern aus gleichzeitig schreibend und lesend zugegriffen werden. Generell müssen die schreibenden Zugriffe synchronisiert werden. Mithilfe des DLM können rechnerübergreifend entsprechende Locks gesetzt werden, so dass z.B. nur ein Rechner schreibenden Zugriff auf das Objekt hat.

  • Parallele Batchläufe
    In einem XCS-Verbund mit zwei Rechnern soll auf Rechner 1 in einem Batchlauf eine Datei mit UPAM erstellt werden. Auf Rechner 2 soll in einem zweiten Batchlauf, ebenfalls mit UPAM, eine sequenzielle Auswertung erfolgen (d.h., auf Rechner 2 ist eine rein lesende Verarbeitung vorgesehen). Erstellung und Auswertung sollen überlappend erfolgen, weshalb der auswertende Batchlauf auf Rechner 2 über den Fortschritt der Dateierstellung auf Rechner 1 informiert werden muss.

    Sobald auf Rechner 1 eine entsprechende Anzahl an Blöcken geschrieben ist, kann über den Lock Value Block eines globalen Locks der Austausch des Blockzählers zwischen Rechner 1 und Rechner 2 erfolgen. Dabei wird auf Rechner 1 der Zähler im Lock-Modus „Exclusive“ oder „Protected Write“ verändert; auf Rechner 2 wird der Zähler im Lock-Modus „Protected Read“ oder „Concurrent Read“ ausgelesen. Die Beendigung der Verarbeitung kann durch Hinterlegen eines speziellen Kennzeichens im Lock Value Block angezeigt werden. Liest Rechner 2 einen als ungültig markierten Lock Value Block, so interpretiert er dies als abnormale Beendigung der Verarbeitung auf Rechner