Koroutinen

Folgende Punkte sind bei Koroutinen wesentlich:

• Mit jeder Koroutine ist ein eigener Kontrollfluß und entsprechend eine eigene Prozedurverschachtelung (Stack) verbunden.
• Zwar können beliebig viele Koroutinen gleichzeitig existieren -- es ist aber nur genau eine davon aktiv zu einem gegebenen Zeitpunkt.
• Koroutinen suspendieren sich freiwillig. Dies kann sowohl explizit (via SYSTEM.CRSWITCH) als auch implizit (durch die Bibliothek) erfolgen.
• Prozeduren, die eine Koroutine repräsentieren, dürfen nicht mit RETURN enden. Statt dessen sollten sie einfach nicht mehr aktiviert werden.
• Nicht mehr erreichbare Koroutinen fallen der automatischen Speicherverwaltung (garbage collection) anheim.

Die folgenden Beispiele zeigen Koroutinen in ihrer Grundform. Normalerweise benötigt man auf Basis der Ulmer Oberon-Bibliothek nur SYSTEM.CRSPAWN zum Kreieren neuer Koroutinen und nicht SYSTEM.CRSWITCH. In einer Reihe von Fällen läßt sich sogar die Verwendung von SYSTEM.CRSPAWN vermeiden.

HaTschi

Ein klassisches Trivial-Beispiel mit zwei sich wechselseitig aktivierenden Koroutinen.

ProdCons

Ein konkretes Beispiel für das Produzenten/Konsumenten-Problem.

Collections-17

Hier wird demonstriert, wie Koroutinen, die implizit von dem Modul Iterators erzeugt werden, statt First und Next zum Durchlaufen von Kollektionen eingesetzt werden können.

Mehr Informationen zu Koroutinen gibt es

• in einem kleinen Artikel, der das Ulmer Koroutinen-Schema mit dem von Modula-2 vergleicht und
• im Report des Ulmer Oberon-Compilers.

Zu beachten ist auch noch folgender Hinweis: Wenn Sie anderen Oberon-Implementierungen begegnen, z.B. denen aus Zürich, dann können Sie leider nicht damit rechnen, daß Koroutinen oder andere Mechanismen zur Parallelisierung unterstützt werden. Obwohl diese Unterstützung kaum vorhanden ist, ist sie für viele Bereiche (insbesondere Netzwerkprogrammierung) und zur Erzielung von Dezentralisierung (und damit Erweiterbarkeit) essentiell.