In diesem Artikel wird untersucht, inwiefern Coroutines einen natürlichen nächsten Schritt in der Evolution der .NET-Nebenläufigkeit darstellen. Zu diesem Zweck werden die theoretischen Grundlagen kooperativer Nebenläufigkeit erläutert, die Implementierungsansätze moderner Sprachen wie Kotlin detailliert analysiert und schließlich auf die Architektur der Common Language Runtime (CLR) übertragen.

Anhand von Codebeispielen in C# und Kotlin wird gezeigt, wie sich ein Coroutine-Scope-, Dispatcher- und Scheduler-System in .NET konzipieren ließe – unabhängig vom bestehenden Task-System oder in komplementärer Koexistenz. Das Ziel hierbei ist, die Diskussion über native Coroutines in .NET zu vertiefen und die Potenziale sowie die Herausforderungen eines solchen Paradigmenwechsels aufzuzeigen.

Einleitung

Die .NET-Plattform gilt seit Jahren als eine der ausgereiftesten Entwicklungsumgebungen für die asynchrone Programmierung. Mit der Einführung von async und await in C# 5.0 im Jahr 2012 wurde die Handhabung asynchroner Operationen revolutioniert [1]. Plötzlich konnten Entwickler:innen nichtblockierende Abläufe schreiben, die sich syntaktisch wie sequenzieller Code lesen. Das zugrundeliegende Modell – Task und Task<T> – baut jedoch auf einem Thread-Pool-basierten, präemptiven System auf, das durch Continuations gesteuert wird. Diese Architektur hat sich zwar als robust erwiesen, stößt aber in bestimmten Szenarien an ihre natürlichen Grenzen.

Parallel dazu haben sich in anderen Sprachen neue Konzepte etabliert, die Asynchronität als kooperative, nicht präemptive Nebenläufigkeit verstehen. Kotlin, Python und C++20 bieten native Coroutines, die es Funktionen ermöglichen, ihren Ausführungszustand zu speichern, zu suspendieren und später fortzusetzen, ganz ohne Thread-Blockierung. Diese kooperative Kontrolle eröffnet neue Möglichkeiten in Bezug auf Effizienz, Lesbarkeit und strukturelle Nebenläufigkeit.

Motivation

Während .NET-Entwickler:innen auf ein umfangreiches Ökosystem aus Tasks, ValueTask, Channels und asynchronen Enumerables zurückgreifen können, fehlt bis heute ein Mechanismus, der Coroutines nativ abbildet. Zwar lässt sich durch IEnumerable und yield return ein rudimentäres Coroutine-Verhalten simulieren, doch hierbei handelt es sich um einen rein synchronen Iterator-Mechanismus. Dieser erlaubt weder echte Suspension noch eine Integration in einen kooperativen Scheduler.

Das zentrale Problem ist struktureller Natur: Das Task-System ist auf Future-ähnliche Resultate und präemptive Scheduling-Mechanismen ausgerichtet. Coroutines hingegen benötigen eine Laufzeitumgebung, die Zustände und Kontrollflüsse explizit verwaltet, ähnlich wie in Kotlin mit suspend und CoroutineScope.

Die Entwicklungen in anderen Ökosystemen werfen die Frage auf, welche Rolle Coroutines zukünftig auch in der .NET-Plattform spielen könnten. Genau darauf geht es im folgenden Abschnitt.

Warum Coroutines in der Industrie zunehmend wichtiger werden

Parallel zur Weiterentwicklung der .NET-Plattform hat sich in der Softwareindustrie ein klarer Trend hin zu kooperativer Nebenläufigkeit abgezeichnet. Immer mehr Sprachen – darunter Kotlin, Python, Rust und C++20 – setzen auf leichtgewichtige Coroutines, um komplexe, verteilte oder reaktive Systeme effizienter zu gestalten. Die Gründe dafür sind vielfältig:

• Steigende Anforderungen an die Skalierbarkeit: Millionen gleichzeitiger Abläufe lassen sich mit kooperativen Coroutines wesentlich ressourcenschonender realisieren als mit Threads.

• Deterministische Ausführung: Anwendungen in Bereichen wie Gaming, Simulation oder Event-Processing profitieren von planbaren, single-threaded Ausführungsmodellen ohne Kontextwechsel.

• Structured Concurrency: Moderne Concurrency-Modelle verlangen klar definierte Lebenszyklen, Fehlerverarbeitung und Abbruchlogik – Eigenschaften, die Tasks in .NET nur eingeschränkt bieten [2].

• Kosten- und Energieeffizienz: Gerade in Cloudumgebungen reduzieren Coroutine-basierte Systeme den Overhead von Thread Scheduling und Synchronisation.

Diese Entwicklung zeigt, dass Coroutines nicht nur eine syntaktische oder architektonische Verbesserung, sondern auch eine Antwort auf die wachsende Komplexität moderner Softwarearchitekturen darstellen. Vor diesem Hintergrund wird zunehmend darüber diskutiert, ob .NET langfristig ebenfalls native Coroutine-Mechanismen integrieren sollte.

SIE LIEBEN C#?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Ziel und Überlegungen

In diesem Artikel geht es um die Machbarkeit und das Potenzial nativer Coroutines in der .NET-Welt. Dabei werden folgende Fragen behandelt:

• Welche Unterschiede bestehen zwischen dem Task-Modell in .NET und dem Coroutine-Modell in Kotlin?

• Wie ließe sich ein Coroutine-Scope und Dispatcher-System in C# implementieren?

• Welche Änderungen wären in der CLR und BCL erforderlich, um kooperative Nebenläufigkeit nativ zu unterstützen?

• Welche Vorteile ergeben sich in praxisnahen Szenarien (z. B. Game Development, Simulation, Realtime-Systeme)?

• Welche Herausforderungen stellen sich in Bezug auf Debugging, Cancellation und Interoperabilität mit bestehenden async-Bibliotheken?

Theoretische Grundlagen der kooperativen Nebenläufigkeit

Unter kooperativer Nebenläufigkeit versteht man ein Ausführungsmodell, bei dem mehrere Prozesse oder Funktionen nicht durch das Betriebssystem präemptiv, sondern durch den Anwendungscode selbst koordiniert werden. Dabei entscheidet jede Routine explizit, wann sie die Kontrolle zurückgibt, anstatt vom Scheduler unterbrochen zu werden. Dadurch entfallen das aufwendige Speichern und Wiederherstellen von Thread-Zuständen und der typische Kontextwechsel.

Das gegenteilige Prinzip ist das präemptive Multi-Threading. Hier entscheidet der Betriebssystemkernel in regelmäßigen Zeitabständen (Zeitscheiben) oder auf Basis von Prioritäten, welcher Thread läuft. Dieser Mechanismus bietet Fairness, führt aber zu Synchronisationsaufwand, Deadlocks und Cacheinvalidierungen.

Kooperative Modelle sind vor allem in Sprachen wie Kotlin, Python oder C++20 wieder in den Fokus gerückt, weil sie einen bewussten Tausch anbieten: etwas mehr Verantwortung im Code gegen deutlich weniger Overhead zur Laufzeit.

Das Prinzip des kooperativen Schedulers

Ein kooperativer Scheduler arbeitet nach dem Prinzip des freiwilligen Yielding. Das heißt, jede Coroutine gibt die Kontrolle nur dann ab, wenn sie eine Suspend-Operation ausführt (z. B. yield, suspend, await). Im Unterschied zum Thread-Pool-Scheduler in .NET muss die Laufzeit keine Zwischenzustände von Stacks und Registersätzen persistieren. Stattdessen reicht es aus, den Fortsetzungspunkt innerhalb der Coroutine zu erfassen, meist durch einen State-Machine-Generator.

Das Beispiel in Listing 1 zeigt ein vereinfachtes Modell eines kooperativen Schedulers in C#. Im Unterschied zum threadbasierten Task-Scheduler arbeitet dieser Ansatz deterministisch: Es gibt keine Race Conditions oder Kontextwechsel zwischen CPU-Kernen. Die Nebenläufigkeit ist rein logisch und findet innerhalb eines einzigen Threads statt, ähnlich wie beim Single-Thread-Event-Loop in JavaScript.

public class CooperativeScheduler
{
  private readonly Queue<IEnumerator> _queue = new();
  public void Start(IEnumerator coroutine) => _queue.Enqueue(coroutine);

  public void Run()
  {
    while (_queue.Count > 0)
    {
      var current = _queue.Dequeue();
      if (current.MoveNext())
        _queue.Enqueue(current); // coroutine yields => reschedule
    }
  }
}

Stack Preservation und Continuation Capturing

Damit eine Coroutine ausgesetzt und später fortgesetzt werden kann, muss die Laufzeit ihren aktuellen Ausführungszustand speichern. In präemptiven Systemen geschieht das implizit durch den Thread-Stack. In kooperativen Modellen hingegen wird dieser Zustand als Continuation-Objekt explizit erfasst.

Kotlin beispielsweise übersetzt eine suspend fun in einen State-Machine-Generator, der lokale Variablen und den Fortsetzungspunkt in einer Klasse speichert [3]. Ein ähnlicher Mechanismus existiert bereits im C#-Compiler für async/await, doch dieser ist an das Task-Objekt gebunden und nicht frei komponierbar.

Eine potenzielle Erweiterung der CLR müsste daher die Möglichkeit bieten, diesen State-Machine-Mechanismus auch für beliebige Coroutine-Typen freizugeben, also beispielsweise Coroutine<T> statt Task<T>.

Integration in moderne Laufzeitumgebungen

Ein modulares Coroutine-System in einer Managed Runtime wie .NET müsste folgende Mechanismen unterstützen:

1. Suspend/Resume-Punkte: Diese Mechanismen ermöglichen es einer Coroutine, ihre Ausführung an definierten Stellen anzuhalten und später nahtlos fortzusetzen, ähnlich wie bei await, ohne dabei auf Task beschränkt zu sein.

2. Kooperativer Scheduler: Der Scheduler steuert die Ausführung von Coroutines unabhängig vom Thread-Pool und lässt sich vollständig durch einen Dispatcher beeinflussen.

3. Structured Concurrency: Jede Coroutine gehört zu einem übergeordneten Scope und wird bei dessen Beendigung automatisch abgebrochen.

4. Cancellation-Tokens oder Scopes: Cancel-Signale werden durch die Scope-Hierarchie weitergereicht.

5. Dispatcher: Ein Dispatcher ermöglicht die Zuweisung von Coroutines zu Threads, z. B. UI-Thread, Worker-Thread oder Background-Scheduler.

Vergleich mit dem .NET-Task-Modell

Das aktuelle Task-Modell stellt eine abstrakte Kapsel für asynchrone Operationen dar. await wartet auf die Fortsetzung eines Tasks, während der Compiler automatisch eine State Machine erzeugt [1]. Dieses Modell ist zwar leistungsfähig, zwingt jedoch jede Asynchronität in das Future/Promise-Paradigma.

Coroutines hingegen sind flexibler: Sie können endlose Prozesse modellieren, kontinuierlich Werte emittieren und einen komplexen Datenfluss abbilden. Kotlin erlaubt dies durch Flow, das als asynchroner Stream aufgebaut ist und intern auf Coroutines basiert [4]. Um vollständige koroutinenbasierte Datenflüsse in .NET zu realisieren, müsste eine ähnliche Struktur existieren, die unabhängig von IAsyncEnumerable<T> ist.

Eine Methode, die IAsyncEnumerable<T> zurückgibt, generiert Elemente nach Bedarf und stellt sie schrittweise zur Verfügung. Dadurch entfällt die Notwendigkeit, die gesamte Sammlung vorab zu laden [3].

Coroutines in modernen Programmiersprachen

Um die Stärken und Schwächen des .NET-Modells besser einzuordnen, lohnt sich zunächst ein Blick auf moderne Programmiersprachen, die native Coroutines unterstützen.

Während präemptive Nebenläufigkeit jahrzehntelang als Standard galt, haben viele moderne Programmiersprachen in den letzten Jahren kooperative Modelle eingeführt. Der Trend hin zu leichtgewichtigeren, strukturierten Coroutines kann als Antwort auf die zunehmende Komplexität verteilter und reaktiver Systeme verstanden werden.

Kotlin: strukturierte Nebenläufigkeit und CoroutineScope

Kotlin gilt als eines der ausgereiftesten Modelle für native Coroutines in Mainstream-Sprachen. Der Schlüssel liegt in zwei Prinzipien:

1. Suspend Functions: Diese Funktionen können ihren Ausführungszustand speichern und später fortsetzen.

   • Structured Concurrency: Jede Coroutine existiert innerhalb eines CoroutineScope, der ihre Lebensdauer kontrolliert [3].

Im Beispiel in Listing 2 ruft launch eine neue Coroutine innerhalb des aktuellen Scopes auf. Die Funktion doWork wird nach einem Delay fortgesetzt, ohne den Thread zu blockieren. runBlocking dient als Brücke zwischen blockierendem und kooperativem Code [4].

import kotlinx.coroutines.*

suspend fun doWork() {
  delay(1000)
  println("Done")
}

fun main() = runBlocking {
  launch { doWork() }
  println("Started")
}

Kotlin-Coroutines haben folgende Eigenschaften:

• Jeder suspend-Call erzeugt intern eine Continuation, die den Zustand der Funktion enthält.

• Der Scheduler wird durch den Dispatcher definiert (Dispatchers.Default, Dispatchers.IO, Dispatchers.Main) [3].

• launch, async, withContext sind Builder-Funktionen, die Coroutines hierarchisch strukturieren.

• Fehler- und Cancel-Propagation erfolgen automatisch durch Scope-Hierarchien.

Dieses Design erlaubt die Ausführung von Millionen Coroutines parallel, ohne dass jemals mehr als einige hundert Threads verwendet werden. Das zugrundeliegende Prinzip ist also kooperatives Multitasking innerhalb strukturierter Sphären – ein klarer Unterschied zum Task-Modell von .NET.

Python: asyncio und der Event Loop

Während Kotlin ein umfassendes Coroutine-Framework bietet, verfolgt Python mit asyncio und async/await ein ähnliches, jedoch leichtgewichtigeres Konzept. Die Implementierung basiert auf einer zentralen Ereignisschleife (Event Loop), die asynchrone Aufgaben kooperativ verwaltet (Listing 3).

import asyncio

async def do_work():
  await asyncio.sleep(1)
  print("Done")

async def main():
  await asyncio.gather(do_work(), do_work())

asyncio.run(main())

Hier sind alle asynchronen Operationen (Tasks), die innerhalb des Event Loop ausgeführt werden [5]. Wichtig: Es handelt sich dabei nicht um Betriebssystem-Threads, sondern um kooperativ verwaltete Coroutines. Das await-Schlüsselwort sorgt dafür, dass die Kontrolle explizit abgegeben wird.

Das Python-Modell bietet folgende Vorteile:

• Es ist einfach und deterministisch, da es nur einen Scheduler (Event Loop) gibt.

• Der Overhead ist sehr gering.

• Es ist ideal für I/O-lastige Anwendungen, weniger für CPU-intensive Prozesse.

Als Nachteile gegenüber Kotlin oder einem hypothetischen .NET-Coroutine-System sind zu nennen:

• Es gibt keine strukturierte Nebenläufigkeit. Jede Coroutine muss also manuell verwaltet werden.

• Es liegt keine tiefe Integration in den Typ-Checker vor (z. B. fehlt statische Suspend-Sicherheit).

• Es existiert kein eingebautes Konzept für Dispatcher oder Thread-Zuordnung.

Ein entscheidender Unterschied besteht also darin, dass Kotlin Coroutines als Sprachkonstrukt mit Laufzeitunterstützung implementiert, während .NET lediglich eine Syntaxebene über Tasks bietet.

Damit lassen sich die jeweiligen Stärken und Schwächen moderner Coroutine-Modelle klar erkennen (Tabelle 1). Im nächsten Abschnitt werden sie dem .NET-Task-Modell systematisch gegenübergestellt.

Die analysierten Sprachmodelle zeigen deutlich, welche Eigenschaften ein modernes Coroutine-System mitbringen sollte (Tabelle 2). Im nächsten Abschnitt wird daher untersucht, inwiefern das aktuelle .NET-Task-Modell diese Anforderungen erfüllt und wo seine Grenzen liegen.

Lehren für .NET

Nachdem die wichtigsten Prinzipien moderner Coroutine-Modelle dargestellt wurden, folgt nun ein Vergleich mit der aktuellen .NET-Architektur.

Die entscheidende Erkenntnis aus den anderen Sprachen ist, dass Coroutines nicht auf Threads basieren müssen, um asynchrone Prozesse effizient zu steuern. Stattdessen genügt ein Mechanismus, der

• den Ausführungszustand einer Methode speichert,

• den Scheduler darüber informiert, wann die Methode fortgesetzt werden soll und

• eine klare Hierarchie (Scope) für Lebenszyklen und Fehlerweitergabe bereitstellt.

Ein mögliches .NET-System müsste also die Vorteile des Task-Modells (Futures, Typisierung, Integration in async/await) beibehalten, den Scheduler jedoch entkoppeln und eine kooperative Steuerung zulassen.

So entstünde eine hybride Architektur: Task für asynchrone Ergebnisse, Coroutine für kooperative Abläufe und strukturierte Concurrency.

Grenzen des Task-Modells

Das Task-Modell ist nach wie vor ein leistungsstarkes Fundament für die asynchrone Programmierung in .NET, stößt jedoch bei feinkörniger Nebenläufigkeit und deterministischen Szenarien an seine natürlichen Grenzen. Ein kooperativer Coroutine-Ansatz könnte hier eine ideale Ergänzung darstellen: nicht als Ersatz für Tasks, sondern als leichtgewichtige Alternative, die auf Scopes, Dispatcher und strukturierte Kontrolle setzt.

Damit stellt sich die Frage, wie ein solches System konkret in .NET realisiert werden könnte, ohne bestehende Anwendungen zu brechen, aber mit klarer architektonischer Trennung vom Thread-Pool. Der folgende Abschnitt entwickelt dazu einen konkreten Architekturvorschlag.

Design einer Coroutines-Infrastruktur in .NET

Ein nativer Coroutine-Mechanismus in .NET sollte keinen Ersatz für Task darstellen, sondern eine komplementäre Erweiterung. Das Ziel ist: kooperative, strukturierte Nebenläufigkeit, leichtgewichtiger als Threads, deterministischer als Tasks, aber tief integriert in das Laufzeitsystem.

Dazu werden folgende Bausteine benötigt:

1. CoroutineScope: definiert Lebenszyklus und Fehlerdomäne

2. CoroutineScheduler: verwaltet die Ausführung kooperativer Routinen

3. Dispatcher: bestimmt, auf welchem Thread oder Kontext eine Coroutine läuft

4. Cancellation: hierarchisch, automatisch weitergereicht

5. Channels und Buffer: Kommunikation zwischen Coroutines

Die Architektur folgt dem Prinzip der „Structured Concurrency“: Jede Coroutine gehört zu einem CoroutineScope. Wird der Scope beendet – sei es normal oder durch einen Fehler –, werden alle untergeordneten Coroutines automatisch abgebrochen.

Dieses Modell garantiert deterministische Lebenszyklen, eine klare Fehler-Propagation und eine einfache Cancellation.

Um dies in .NET praktisch abzubilden, sind eine Reihe klar definierter Laufzeitkomponenten erforderlich, die Suspension-Punkte, Lebenszyklen und kooperatives Scheduling verwalten. Die folgende Architektur orientiert sich konzeptionell an Kotlin und zeigt, wie ein vergleichbares System in C# strukturiert werden könnte.

CoroutineScope – Lebenszyklusverwaltung

Listing 4 zeigt ein einfaches Beispiel in C#, Listing 5 in Kotlin. Der Unterschied besteht darin, dass Kotlin diese Semantik direkt in seine Standardbibliothek integriert, während .NET dafür eine benutzerdefinierte Laufzeitstruktur bräuchte.

public class CoroutineScope : IDisposable
{
  private readonly List<IEnumerator> _coroutines = new();
  private readonly CoroutineScheduler _scheduler;
  private bool _isCancelled;

  public CoroutineScope(CoroutineScheduler scheduler)
  {
    _scheduler = scheduler;
  }

  public void Launch(IEnumerator coroutine)
  {
    if (_isCancelled) return;
    _coroutines.Add(coroutine);
    _scheduler.Schedule(coroutine);
  }

  public void Cancel()
  {
    _isCancelled = true;
    _coroutines.Clear();
  }

  public void Dispose() => Cancel();
}

val scope = CoroutineScope(Dispatchers.Default)

scope.launch {
  repeat(5) {
    delay(500)
    println("Running $it")
  }
}

CoroutineScheduler – das Herzstück

Der Scheduler koordiniert die Ausführung der Coroutines innerhalb eines Threads. In einer minimalen Variante könnte er wie Listing 6 aussehen.

public class CoroutineScheduler
{
  private readonly Queue<IEnumerator> _queue = new();

  public void Schedule(IEnumerator coroutine)
  {
    lock (_queue)
      _queue.Enqueue(coroutine);
  }

  public void Run()
  {
    while (_queue.Count > 0)
    {
      IEnumerator current;
      lock (_queue)
        current = _queue.Dequeue();

      if (current.MoveNext())
        Schedule(current);
    }
  }
}

Das Prinzip ist, dass jede Coroutine durch yield return die Kontrolle freiwillig abgibt. Der Scheduler ruft sie später erneut auf – kooperativ und ohne Thread-Wechsel. In einem realen System käme ein Tick-Mechanismus (ähnlich einem Game Loop) zum Einsatz, der pro Frame oder Intervall Coroutines ausführt.

Dispatcher – Trennung von Kontexten

Ein Dispatcher definiert, wo eine Coroutine ausgeführt wird. In Kotlin beispielsweise mit

launch(Dispatcher.IO){ /* läuft auf IO-Thread */ }

In .NET könnte man Dispatcher so realisieren wie Listing 7 zeigt.

public interface IDispatcher
{
  void Dispatch(Action action);
}

public class UiDispatcher : IDispatcher
{
  private readonly SynchronizationContext _context;

  public UiDispatcher(SynchronizationContext context)
    => _context = context;

  public void Dispatch(Action action)
    => _context.Post(_ => action(), null);
}

public class ThreadPoolDispatcher : IDispatcher
{
  public void Dispatch(Action action)
    => ThreadPool.QueueUserWorkItem(_ => action());
}

Damit wäre es möglich, Coroutines gezielt bestimmten Kontexten zuzuweisen, ohne dabei die globalen SynchronizationContext zu verändern.

Scheduler und Dispatcher bilden damit gemeinsam das Fundament eines vollständig kooperativen Ausführungsmodells, das unabhängig vom Thread-Pool arbeitet und dennoch eine präzise Kontrolle über Ausführungskontexte ermöglicht.

Cancellation und strukturierte Abbrüche

Einer der größten Vorteile von Kotlin Coroutines ist ihre strukturierte Cancellation. Ein Abbruchsignal an den Scope wird automatisch an alle untergeordneten Coroutines weitergegeben. In .NET könnte man dies so modellieren, wie es in Listing 8 zu sehen ist.

public class CancellationScope
{
  private readonly List<IEnumerator> _children = new();
  private bool _isCancelled;

  public void Register(IEnumerator coroutine) => _children.Add(coroutine);

  public void Cancel()
  {
    _isCancelled = true;
    _children.Clear();
  }

  public bool IsCancelled => _isCancelled;
}

Jede Coroutine prüft regelmäßig scope.IsCancelled und beendet sich kooperativ (Listing 9).

IEnumerator Worker(CancellationScope scope)
{
  while (!scope.IsCancelled)
  {
    Console.WriteLine("Working...");
    yield return new WaitForSeconds(0.5);
  }
}

Channel Buffering und Backpressure

Die Kommunikation zwischen Coroutines kann über Channels erfolgen, ähnlich wie in Kotlin oder Go. Diese können unbounded (mit unbegrenztem Puffer) oder bounded (mit begrenztem Speicher) sein (Listing 10). Das Beispiel in Listing 11 zeigt einen Producer-Consumer mit Channel Buffering. Hier entsteht Backpressure automatisch, wenn der Buffer voll ist. Das System bleibt deterministisch und steuerbar.

public class Channel<T>
{
  private readonly Queue<T> _queue = new();
  private readonly int? _capacity;

  public Channel(int? capacity = null)
  {
    _capacity = capacity;
  }

  public void Send(T value)
  {
    if (_capacity.HasValue && _queue.Count >= _capacity.Value)
      throw new InvalidOperationException("Buffer full");
    _queue.Enqueue(value);
  }

  public bool TryReceive(out T value)
  {
    if (_queue.Count == 0)
    {
      value = default!;
      return false;
    }
    value = _queue.Dequeue();
    return true;
  }
}

var channel = new Channel<int>(capacity: 3);
scope.Launch(Producer(channel));
scope.Launch(Consumer(channel));

IEnumerator Producer(Channel<int> ch)
{
  for (int i = 0; i < 10; i++)
  {
    ch.Send(i);
    yield return new WaitForSeconds(0.1);
  }
}

IEnumerator Consumer(Channel<int> ch)
{
  while (true)
  {
    if (ch.TryReceive(out var value))
      Console.WriteLine($"Received: {value}");
    yield return null;
  }
}

Integration mit async/await

Um Kompatibilität mit bestehendem Code zu gewährleisten, müsste eine Brücke zwischen Task und Coroutine existieren (Listing 12). Damit ließen sich bestehende Bibliotheken schrittweise migrieren oder hybrid betreiben.

public static class CoroutineInterop
{
  public static IEnumerator FromTask(Task task)
  {
    while (!task.IsCompleted)
      yield return null;
  }

  public static Task ToTask(IEnumerator coroutine)
  {
    var tcs = new TaskCompletionSource();
    var scheduler = new CoroutineScheduler();

    scheduler.Schedule(Wrap(coroutine, tcs));
    scheduler.Run();
    return tcs.Task;
  }

  private static IEnumerator Wrap(IEnumerator coroutine, TaskCompletionSource tcs)
  {
    while (coroutine.MoveNext())
      yield return coroutine.Current;
    tcs.SetResult();
  }
}

Von bibliotheksbasierten Simulationen zu nativer Laufzeitunterstützung

Die bisherigen Beispiele zeigen, wie Coroutines heute in .NET mit Iteratoren oder benutzerdefinierten Schedulern simuliert werden können. Diese Ansätze sind zwar funktionsfähig, bleiben jedoch rein bibliotheksbasiert und können die CLR nicht vollständig entlasten.

Um Coroutines ähnliche Eigenschaften wie in Kotlin zu verleihen – etwa echte Suspend Points, strukturelle Cancellation und tief integrierte Dispatcher –, wären Änderungen auf Ebene der Laufzeitumgebung notwendig. Genau diese potenziellen Erweiterungen sind Thema des folgenden Abschnitts.

Ausblick: native Unterstützung in der CLR

Welche Laufzeiterweiterungen wären notwendig, um Coroutines tief in die Architektur von .NET zu integrieren? Eine offizielle Integration in .NET würde tiefgreifende Erweiterungen der Common Language Runtime (CLR) erfordern.

Neue IL-Codes: suspend, resume, yield

Gemäß dem ECMA-335-Standard, der die interne Funktionsweise von .NET spezifiziert, sind solche Opcodes derzeit nicht vorhanden [6]. Deshalb kann die CLR Funktionen nicht an beliebigen Punkten „einfrieren“ und später fortsetzen.

Laufzeitverwaltung für Coroutine-Frames

Die CLR müsste lernen,

• den vollständigen Zustand einer Funktion beim Aussetzen zu speichern,

• diesen Zustand später wiederherzustellen und

• das Ganze sauber in den Garbage Collector zu integrieren.

Ein solcher Mechanismus ist im aktuellen Standard nicht enthalten.

API für Dispatcher und Scheduler in System.Threading.Coroutines

Es wäre eine Standardbibliothek nötig für

• kooperatives Scheduling

• Dispatcher

• Interaktion mit mehreren Threads

Es geht also um das Coroutine-Gegenstück zu Task und der Task Parallel Library.

Debugging-Unterstützung für fortsetzbare Methoden

Der Debugger müsste verstehen,

• welche Zustände eine Coroutine hat,

• welche Variablen in welchem Frame liegen und

• wie das Fortsetzen Schritt für Schritt funktioniert.

Aktuell kann .NET das nicht nativ.

Interoperabilität mit async/await

Coroutines und async/await müssten eine gemeinsame Continuation-Struktur verwenden, um sauber miteinander zu funktionieren.

Umsetzung über Compiler und IL-Transformation

Die Umsetzung sähe ähnlich aus wie bei async/await:

• Der Compiler würde den Code in IL transformieren.

• Die IL würde die neuen Opcode-Erweiterungen nutzen,

• aber ohne Task als Grundlage, also unabhängig von der Task Parallel Library.

Solche Änderungen würden die CLR in ähnliche Regionen bringen wie moderne Runtimes in Kotlin oder C++.

Fazit

Coroutines sind ein leistungsfähiges und zugleich leichtgewichtiges Modell kooperativer Nebenläufigkeit. Moderne Sprachen wie Kotlin oder C++20 zeigen, dass Suspend- und Resume-Mechanismen, strukturierte Concurrency und konfigurierbare Dispatcher erhebliche Vorteile gegenüber rein präemptiven Thread-Modellen bieten.

Für .NET ergibt sich daraus eine interessante Perspektive: Das Task-Modell bildet weiterhin ein stabiles Fundament für Future-ähnliche Operationen, stößt bei deterministischen, feingranularen und langlaufenden asynchronen Abläufen jedoch an seine natürlichen Grenzen. Ein natives Coroutine-System könnte diese Lücke schließen, ohne die bestehende Architektur zu ersetzen.

Die technische Analyse zeigt jedoch deutlich, dass eine echte Integration über reine Bibliothekslösungen hinausgehen müsste. Suspend-Punkte, Continuation-Frames, strukturierte Cancellation und Dispatcher wären nur dann vollständig und performant abbildbar, wenn die CLR und damit auch der ECMA-335-Standard erweitert würden.

Ob .NET diesen Schritt gehen wird, ist offen. Doch die wachsende Bedeutung kooperativer Nebenläufigkeit in der Softwareindustrie lässt vermuten, dass dieses Thema langfristig an Relevanz gewinnen wird. Native Coroutines könnten für .NET einen logischen nächsten Evolutionsschritt darstellen, vergleichbar mit der Einführung von async/await vor über einem Jahrzehnt.

Ein solcher Schritt würde zwar tiefgreifende Änderungen am .NET-Ökosystem erfordern, der Nutzen wäre jedoch klar erkennbar und die Basis dafür ist bereits in vielen Teilen vorhanden. Langfristig könnte die native Unterstützung von Coroutines daher nicht nur eine technische Erweiterung darstellen, sondern einen fundamentalen Schritt hin zu einem moderneren, deterministischeren und besser skalierbaren .NET-Ökosystem bedeuten.

Links & Literatur

[1] https://learn.microsoft.com/dotnet/csharp/asynchronous-programming/
[2] Ford, N.; McCann, C.; Okasaki, R.: „Structured Concurrency: The Bright Future of Async Programming“; Communications of the ACM, 2021
[3] https://kotlinlang.org/docs/coroutines-overview.html
[4] https://elizarov.medium.com
[5] https://docs.python.org/3/library/asyncio.html
[6] https://www.ecma-international.org/publications-and-standards/standards/ecma-335/