Asynchrone Programmierung mit async/await in .NET (I)

Das neue Jahr bringt neue Paradigmen – fast&fluid wird Mainstream im GUI und asynchrone Programmierung generell damit eine Notwendigkeit. Wer kennt es nicht: nach einem Click in einer GUI Anwendung, welche auf einem starken Rechner mit guter single-und Multithreaded Performance läuft, scheint sie trotzdem festzustecken; man sagt die Anwendung “blockiert” (engl. blocked), was häufig durch Anwendungs Workload auf dem User Interface (UI) Thread hervorgerufen wird. Dem Anwender bleibt nichts anderes übrig als zu warten bis die blockierende Operation endet um das GUI weiter verwenden zu können. Das Problem von blocking Behavior ist allerdings nicht nur auf den Client beschränkt. Eine Server-seitige multi-threaded Anwendung kann schnell den Zustand eines ausgeschöpften Thread-Pools erreichen, wenn einzelne Threads z.B. für I/O Operationen blockieren. In der 3-teiligen Serie werden wir sehen, wie das neue async/await in .NET asynchrone Programmierung in vernünftiger Granularität zum Default Ansatz gegen Blocking machen soll.

Synchron-Asynchron

Die Programmausführung in dem Kontext wird auch als synchron bezeichnet; Programmschritte durchlaufen ein sequentiell Muster. Ein Programm Statement kommt erst zur Ausführung nachdem das Vorherige beendet wurde. Eine synchron aufgerufene Methode retouniert den Programmfluss erst wieder an den Aufrufer sobald sie selbst abgeschlossen ist. Synchrone Abläufe im weiteren Sinn inkludiert auch die Verarbeitung nach einem strickten Zeittakt wie in synchronen Netzen, parallele Modelle wie SIMD (single instruction multiple data) in GPUs und Pipelining in aktuellen CPUs.

Asynchrone Programmierung hingegen erlaubt die Ausführung von Programmteilen ohne der vorherigen Beendigung anderer Prozesse und Methoden. Nach einem asynchronen Aufruf springt das Programm sofort wieder zum Aufrufer zurück, die Resultate liefert die aufgerufene Methode sobald fertig. Lang laufende Operationen (engl.: long-running) müssen damit nicht zu Blocking Verhalten der Anwendung führen. Praktische Vorteile von Asynchronität sind flüssige GUIs am Client, höhere Skalierbarkeit von server-seitigem Code, und besseres Antwortzeit Verhalten von Enterprise Anwendungen.

Nun stellt sich die Frage warum nicht schon immer asynchron programmiert worden ist? Die Antwort war bis jetzt zumeist dass es wesentlich komplexer ist, es nicht dem omnipräsenten sequentiellen Gedankenmodell entspricht, Concurrency Issues entstehen können und Test/Debug entsprechend schwieriger sein kann. In einer Abgrenzung zur Parallel Programmierung werden wir sehen, dass async/await in .NET nicht parallel ist und letztere Hindernisse in der Async Verwendung größtenteils ausräumt.

Asynchrone Programmier Modelle in .NET

In .NET sind bereits eine Reihe an asynchronen Programmier Modellen vorhanden. async/await und der Task-based Asynchronous Pattern ist nur die letzte Iteration Asynchron in den .NET Mainstream zu bringen. .NET 1.0 inkludierte neben dem umfangreichen System.Threading.Thread, welches natürlich auch für Asynchron verwendet werden kann, das vergleichsweise komfortablere Asynchronous Programming Model (APM). Mit den Konstrukten Begin/End in dem sog. IAsyncResult Pattern hat zum Beispiel die FileStream Klasse Methoden zum asynchronen Lesen/Schreiben als Begin{Read, Write}. Die asynchrone Operation läuft dabei in einem separaten Thread. Resultate werden entweder über IAsyncResult Objekte direkt oder Callbacks mit IAsyncResult retouniert.

Ebenfalls seit .NET 1.0 kann über APM hinausgehend jede Methode über einen Delegate asynchron aufgerufen werden. Der Delegate ist dabei ein Wrapper zur synchronen Methode; die CLR startet dann via Delegate ein Replika der Methode in einem Worker Thread.

Der Event-based Asynchronous Pattern (EAP) kam mit .NET 2.0 hinzu, womit APM depreciated wurde. EAP Methoden und Events im Framework haben das Namensschema {Operation}Async respektive {Operation}Completed. Eine häufig verwendete Methode ist z.B. WebClient.DownloadFileAsync, ein weiterer Namespace mit einigem EAP Support ist System.Net. System.ComponentModel.BackgroundWorker ist der universelle Weg in EAP Threads aus dem ThreadPool zu nutzen.

Die Task Parallel Library (TPL) brachte umfangreiche Library-und Language Enhancements für vor allem multi-threaded und paralleles Programmieren (Parallel.For, PLINQ etc.) Die darin enthaltenen System.Threading.Tasks.Task und Task<T> “Task Klassen” sind nicht nur Basis für das folgende async/await sondern können auch in dem APM und EAP Patterns verwendet werden.

Zur Umsetzung des Dataflow Paradigmas-Skeletons gibt es seit .NET 3.5 SP1 die Reactive Extensions (Rx). Ähnlich den vorherigen asynchronen Ansätzen bei denen der Kontrollfluss eines Programmes asynchron abläuft erlaubt Dataflow automatisches asynchrones Propagieren von Datenänderungen. Rx nutzt IObservable<T> für Notifications zu Datenänderungen, und LINQ-Operatoren. Mit .NET 4.5 kommt komplementär die umfangreiche TPL Dataflow Library (System.Threading.Tasks.Dataflow) hinzu. Wesentliche Eigenschaften der TPL Library sind ein low-level Message Passing Ansatz für hohen Throughput und geringe Latency sowie die Zusammensetzbarkeit (engl.: composability) mit anderen async Konstrukten und Libraries wie zum Beispiel async/await. Rx und TPL vereinfachen Data Concurrency ungemein.

Weiter zu Teil II (async/await) und Teil III (Beispiel Anwendung) sobald gepostet.

Downloads

Async Support ist in aktuell 3 verschiedenen Downloads enthalten:
(a) Async CTP: AsyncCtpLibrary.dll als Reference hinzufügen,
(b) VS11 mit .NET 4.5 und
(c) .NET 4.5 CTPv3: ein side-by-side Update von .NET <= 3.5 und in-place Update für 4.0. Achtung: da bei dem in-place Update zu z.B. dem Task Typ keine neuen statischen Members zu System.Threading.Tasks.Task hinzugefügt werden können haben manche Types zwischenzeitlich differierende Namen wie TaskEx. Zum Download:

Download VS11 mit .NET 4.5 CTP Download .NET 4.5 CTP Download Async CTP Version 3(Beispiel in Teil III verwendet Async CTPv3)

Task-based Asynchronous Pattern (Stephen Toub)

Disclaimer:
Allgemeine rechtliche Hinweise