Koroutinen
« | 18 Sep 2021 | »Mit C++20 werden
Koroutinen
(#include <coroutine>) in den Sprachstandard aufgenommen.
Mich wundert aber, dass im nächsten C Standard (C2x)
von Koroutinen keine Rede ist.
Also habe ich mich mal in den Betriebssystemen umgesehen, wie man Koroutinen selbst implementieren kann.
Vorgeschichte
Definition: Ich verstehe unter Koroutinen die Möglichkeit, einen
“synchronen” Ausführungskontext anzuhalten und auf einen anderen zu wechseln.
Eigentlich meine ich damit eine Form des User-Mode-Thread-Scheduling.
Diverse “akademische” Spielereien, wo man selbst eine State-Machine
implementiert und eine Funktion manuell in Stücke zerlegt und diese aufruft,
fällt für mich nicht unter das Sprachenkonstrukt “Koroutinen”, wenn gleich
man funktional damit das Gleiche machen kann.
Ich möchte also mehrere Ausführungskontexte in einer logischen Einheit
- starten (create)
- gezielt aktivieren (switch_to)
- beliebig zum nächsten Kontext wechseln (yield)
- abwarten können (wait)
Persönlich gab es für mich noch nie einen Grund, bewusst Koroutinen
einzusetzen, sie sind für mich eher nur Syntax-Zucker.
Ich gebe aber zu, dass es Konstellationen gibt (z.B. in Callback-Funktionen),
wo es hilfreich sein kann, einfach auf einen anderen Callstack zu wechseln um
dort etwas abzuarbeiten, ohne dass man gleich Kernel-Threads und
Messagequeues dafür einsetzt.
Win32 Fiber API
Windows kennt seit Win32/WinNT Fibers (Fasern) als Untermenge von Threads (Faden). Ein Thread führt in der Regel genau einen Callstack mit sich, arbeitet also “eine Faser (=Fiber)” ab. Man kann aber einen Thread in eine Fiber umwandeln und weitere Fibers erzeugen und dann per API zwischen diesen “Fasern” hin und herwechseln. Es läuft immer nur ein aktiver Fiber in dem Thread, und alle anderen sind angehalten (werden also nicht ausgeführt).
Mit dieser Technik kann man Koroutinen relativ einfach implementieren, in dem man eine Scheduler-Fiber-Funktion nutzt, die sequentiell andere registrierte Fiber-Koroutinen-Kontexte aktiviert. Wenn eine Fiber-Koroutine zu einer anderen wechseln möchte, teilt sie das über eine gemeinsame Variable mit und wechselt dann zur Scheduler-Fiber, die die Anweisung korrekt umsetzt.
Und wenn jetzt zu jeder Fiber noch ein completed Flag gespeichert wird,
das beim Verlassen einer Koroutinen-Funktion gesetzt wird, dann kann man
auch ein wait Feature implementieren, womit dann eine wartende Koroutine
so lange nicht weiterläuft, bis die “erwartete” andere Routine fertig ist.
Folgende Windows API sind sehr hilfreich:
Eigentlich gibt es dann noch die Funktion ConvertFiberToThread mit welcher man einen Fiber-Thread wieder zu einem normalen Thread machen kann. Da diese Funktion aber erst mit Server 2003 eingeführt wurde und ich Koroutinen sowieso Thread-technisch abkapseln möchte, starte ich einen eigenen Thread für eine Koroutinen-Session. Wird dieser beendet, sterben seine “Fasern” mit ihm und ich muss mir keine Gedanken über COM-Aufrufe oder Ähnliches machen.
Linux/POSIX ucontext
POSIX hatte mit dem ucontext.h Header ebenfalls ein Werkzeug bereitgestellt,
mit dem man selbst einen Stack-Block allokieren und damit einen neuen
Aufrufkontext erstellen und dann darauf hinwechseln kann.
Auch hier kann man ganz analog zu Windows Fibers mehrere Aufrufkontexte als Teil eines Threads erstellen und dann manuell zwischen diesen hin- und herwechseln.
Die notwendigen APIs lauten:
Interessant ist, dass man den zu nutzenden Stack-Speicher mit malloc selbst
bereitstellen kann, es wäre aber auch erlaubt, einfach ein paar Kilobytes des
eigenen Stack-Frames für die Koroutine einzusetzen, in dem man einfach ein
char coroutine_stack[16384] in die eigene Routine schreibt.
Aber um Stapelüberläufe zu verhindern, sollte man eher den ersten Weg gehen.
Einen fetten Nachteil gibt es leider: ucontext wurde nachträglich wieder
aus dem POSIX Standard entfernt. Linux hat dieses Feature großteils
beibehalten, aber Systeme wie OpenBSD haben es aus seiner Implementierung
gestrichen.
Meine vorläufig einzige Möglichkeit für Koroutinen auf solchen Systemen ist der Einsatz von “echten” Threads für jede Koroutine, die einfach schlafen gelegt werden, wenn sie einen Kontext-Wechsel einfordern.
Fazit
Am Ende verstehe ich das Problem, warum C++20 hier sein ganz eigenes Koroutinen-Konzept in die Sprache einbaut und nicht auf Bibliotheken zurückgreift:
Andere Koroutinen-Implementierungen (wie lib coro) brauchen am Ende Assembler-Blöcke für jeden möglichen CPU-Typ, um Koroutinen auf jede Plattform bringen zu können, weil das OS diesen Support nicht immer bietet, und auch Mikrocontroller sind davon ausgeschlossen.
Man müsste dieses Feature also in die Core-Language aufnehmen und gegen solche Änderungen sträubt sich C, weil es seine Einfachheit verlieren könnte.
C++ leistet sich diesen Luxus hingegen und wird (so meine Erwartung) vermutlich damit den bestmöglichen Koroutinen-Support anbieten können, den man sich vorstellen kann.
Ein Problem wird es aber meines Erachtens immer geben: Bestehende Bibliotheken oder auch Betriebssysteme kennen das C++20 Koroutinen Modell nicht und wenn man diese mit nativen Funktionen mischt, könnten mehrere Seiteneffekt auftreten.
Man denke an native Warte-Routinen oder andere eigene oder systemspezifische
Implementierungen.
Von daher würde ich Koroutinen in der Systemprogrammierung auch weiter
nicht einsetzen … und das ist schon ein bisschen Schade.
Beschränkt man sich aber auf Mathematik und nur auf std Implementierung,
haben Koroutinen sicher ein ordentliches Potential.
Und ich kann mit meinen Implementierung in C zumindest ein bisschen auf dieser Welle mitreiten, wohl wissend, dass diese Variante ebenso anfällig für Seiteneffekt ist.