Traditionelle Programmiersprachen und -systeme bieten nur einen einzigen Kontrollfluß an. Dies ist extrem einschränkend, da es dann beispielsweise nicht ohne weiteres möglich ist, parallel zur Interaktion mit dem Benutzer mit anderen Prozessen über das Netzwerk zu kommunizieren. Entsprechend ergeben sich Konflikte bezüglich der Zeit aus einer begrenzten Parallelisierbarkeit.
Heute sollte jede Programmumgebung Parallelität in der einen oder anderen Form anbieten, da sonst viele Techniken schlichtweg unmöglich sind - es sei denn auf Kosten der Unabhängigkeit der einzelnen Module (wenn z.B. die Benutzerinteraktion gezwungen ist, regelmäßig das Netzwerk auf neue Pakete abzufragen) oder alles muß in Form von Ereignis-Häppchen in möglichst kurzer Zeit abgearbeitet werden. Dies wird beispielsweise bei Java standardmäßig unterstützt - bei anderen Systemen sieht es teilweise ziemlich düster aus.
Oberon sieht in der Sprachdefinition nur einen einzigen Kontrollfluß vor. Diese Restriktion wurde im Ulmer Oberon-System durch die Einführung von Koroutinen gelockert. Da jedoch immer nur eine Koroutine aktiv sein kann, müssen auch Koroutinen untereinander kooperieren, indem sie die Ausführung der anderen Koroutinen nicht unnötig blockieren.