Bedingungen

Bedingungen sind ein im Rahmen der Ulmer Oberon-Bibliothek entwickeltes Sprachmittel, das eine gewisse Nähe zu asynchronen Signalen hat. Jede konkrete Bedingung bezieht sich auf ein bestimmtes Ereignis, das möglicherweise schon eingetreten ist oder in der Zukunft möglicherweise zu erwarten ist. Jederzeit ist es möglich, eine Bedingung zu befragen, ob das Ereignis bereits eingetreten ist oder nicht. Dabei ist allerdings unter Umständen eine Zeitverzögerung zu berücksichtigen, d.h. daß eine Bedingung erst einige Zeit später wahr wird, nachdem das zugehörige Ereignis eingetreten ist. Wenn ein Ereignis eintritt, können damit verbundene Informationen den Weg zu der sich darauf beziehenden Bedingung nehmen, so daß auf dieser Basis eine asynchrone Kommunikation möglich ist.

Im Unterschied zu dem vorgestellten Modell der asynchronen Kommunikation findet kein explizites Versenden eines Signals oder einer Anfrage statt. Wenn der Empfänger eine Bedingung kreiert, führt dies implizit zu dem Versenden des Signals, wo immer das Ereignis auch eintritt. Damit stellt sich auch nicht die Frage, was passiert, wenn ein Signal abgesendet wird, ohne daß der Empfänger darauf vorbereitet ist.

Für Bedingungen gibt es in der Ulmer Oberon-Bibliothek die Abstraktion Conditions und zahlreiche Implementierungen, die jederzeit ergänzt werden können. Der Umgang entspricht etwa folgendem Muster:

• Zunächst kann eine Partei für sich konkrete Bedingungen kreieren. Wichtig ist dabei, daß jede Partei ihre eigenen Bedingungen kreiert - selbst wenn mehrere Parteien an dem gleichen Ereignis interessiert sind.

  VAR xxxcond, yyycond: Conditions.Condition;
  (* ... *)
  XXXConditions.Create(xxxcond);
  YYYConditions.Create(xxxcond);
  

• Jederzeit ist es möglich, den aktuellen Wert einer Bedingung abzufragen:

  IF Conditions.Test(xxxcond, errors) THEN
     (* das Ereignis ist eingetreten oder
        wird moeglicherweise nie eintreten (errors ueberpruefen!)
     *)
  ELSE
     (* das Ereignis ist noch nicht eingetreten *)
  END;
  

• Unter Verwendung eines Schedulers (in der Ulmer Oberon-Bibliothek über Tasks erreichbar, kann die aktuelle Task (entspricht einer Koroutine, mehr dazu etwas später) bis zum Eintreffen eines Ereignisses (oder dem Feststellen, daß das Ereignis nicht eintreffen kann) suspendiert werden:

  Tasks.WaitFor(xxxcond);
  

• Es ist auch möglich, auf das Eintreffen eines Ereignisses aus einer Menge von Ereignissen zu warten:

  VAR condset: Conditions.ConditionSet;
  (* ... *)
  Conditions.CreateSet(condset);
  Conditions.Incl(condset, xxxcond);
  Conditions.Incl(condset, yyycond);
  Tasks.WaitForOneOf(condset);
  

  Statt Tasks.WaitForOneOf kann auch Tasks.Select verwendet werden, wenn die Menge der wahr gewordenen Bedingungen von Interesse ist.

Zwar sind die Operationen für Bedingungen einheitlich, aber das Umgangsschema mit Bedingungen kann durchaus unterschiedlich sein. Es gibt dabei vier Grundvarianten:

Globale Ereignisse

sind für alle Parteien jederzeit abfragbar. Insbesondere ist es auch möglich nach dem Eintreten des Ereignisses noch die zugehörige Bedingunge zu kreieren und zu erfahren, daß es stattgefunden hat. Ein Beispiel hierfür sind TimeConditions, die das Eintreten eines bestimmten Zeitpunkts bei einer Uhr als Ereignis betrachten.

lokale Ereignisse

haben genau zwei Parteien, bei denen eine Partei das Ereignis geschehen läßt, an dem die andere Partei interessiert ist. Ein Beispiel hierfür sind StreamConditions und typischerweise wartet die eine Partei darauf, etwas lesen zu können, das die andere Partei schreibt.

Gruppenereignisse

können für beliebig viele Parteien interessant sein. Um das Eintreten des Ereignisses mitzubekommen, ist es notwendig, sich (implizit durch das Kreieren der entsprechenden Bedingung) zu registrieren. Typischerweise ist es dann auch noch notwendig, den Empfang der Information über ein eingetretenes Ereignis zu quittieren (damit es nicht mehr länger aufbewahrt werden muß) und explizit die Registrierung zurückzunehmen, wenn kein Interesse mehr vorliegt (damit die Informationen üeber die Ereignisse sich nicht ungenutzt aufsammeln). Typischerweise werden Gruppenereignisse zur Kommunikation einer Gruppe von Tasks untereinander verwendet. In der Bibliothek bietet sich dafür EventConditions an.

Konkurrierende Ereignisse

treten bei einer Synchronisierung zum gegenseitigen Ausschluß für den Zugriff auf eine Ressource auf. Hier gibt es beliebig viele Parteien, die an einem Zugriff interessiert sind, und das ersehnte Ereignis ist, daß die eigene Partei den Zugriff erhält. Das klassische Beispiel dafür sind Semaphores.