Advertisement

Eine Betriebssystem-Erweiterung zur Programmierung mit aktiven Objekten: der Event-Distribution-Mechanismus (EDM)

  • Peter A. Gloor
Part of the Leitfäden der angewandten Informatik book series (XLAI)

Zusammenfassung

Der hier eingeführte Mechanismus soll die ereignisgesteuerte Programmierung (event driven programming) auf Betriebssystem-Ebene ermöglichen. Programmierung mit Mechanismen dieser Art wird in der Literatur auch als Programmierung mit aktiven Objekten” bezeichnet [Int86][Nie87]. Unter aktiven Objekten müssen nicht unbedingt Objekte verstanden werden, die unabhängig voneinander wirklich aktiv sein können, d.h. Objekte, die letztlich durch einen eigenen Prozess dargestellt werden. Vielmehr versucht man, sich die Objekte auf einer abstrakteren Ebene als aktive, voneinander unabhängige Entitäten vorzustellen. Die bei der hier beschriebenen Implementation unter UNIX angesprochenen Objekte werden natürlich Prozesse sein, die mit Hilfe von Events miteinander kommunizieren, d.h. zwar aktive, aber nicht persistente Objekte, deren Lebenszeit auf ihren Aufenthalt im Hauptspeicher beschränkt ist.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literratur

  1. 1.
    Falls die zum blockierenden Event gehörenden Aktionen idempotent sind (d.h. der Effekt einer Aktion ist derselbe, unabhängig davon, ob die Aktion ein oder mehrere Male ausgeführt wird), so muss der Anwender das Event lediglich solange wiederholen, bis es erfolgreich zu Ende geführt werden konnte.Google Scholar
  2. 2.
    In einer späteren Implementation ist es dann ein Leichtes, den Master dynamisch mit Hilfe eines aus der Literatur bekannten Algorithmus wie z.B. [Gar85] zu bestimmen. Zur Erkennung des Zusammenbruchs des Masters kann z.B. das Zerfallsprinzip, wie es in Kapitel 6 beim Decaying Lock vorgeschlagen wird, verwendet werden: Falls sich der momentane Token-Master auf eine Anfrage nicht innerhalb einer bestimmten Timeout-Zeit meldet, so wird dynamisch ein neuer Netzwerkknoten zum Master bestimmt.Google Scholar
  3. 3.
    Die Spezifikation der Event-Handler-Funktion für das Event unlock wird hier ausgelassen. Diese Event-Handler-Funktion kann durch eine vereinfachte Version der Event-Handler-Funktion für das Event lock realisiert werden.Google Scholar
  4. 4.
    Auf eine Ressource können zur gleichen Zeit beliebig viele Read-Locks angelegt werden, jedoch nur ein Write-Lock aufs Mal.Google Scholar
  5. 5.
    Diese Eigenschaft blockierender Events wurde bereits bei der Implementation des Locking-Service von Kapitel 4.1. verwendet. Die Konsistenz der replizierten Lock-Tabelle wurde auf diese Weise gewährleistet.Google Scholar

Copyright information

© B. G. Teubner Stuttgart 1989

Authors and Affiliations

  • Peter A. Gloor
    • 1
  1. 1.Universität ZuürichDeutschland

Personalised recommendations