Asynchrone Programmierung mit async/await

[helicopta]

Guten Abend,

Das ist mein erster Beitrag hier. Ich habe im Sommer meine Umschulung zum FI für Anwendungsentwicklung abgeschlossen, bin also quasi Neuling.

Ich habe ein Verständnisproblem mit der Asynchronen Programmierung und hoffe das Ihr mir helfen könnt. Ich habe schon einige Artikel und Literatur 

zu dem Thema gelesen und doch bin ich scheinbar nicht klug genug um zu begreifen, wann eine async Methode Sinn macht und warum.

So wie ich das verstanden habe wird eine Methode die mit dem async Keyword markiert ist automatisch in einem neuen Thread ausgeführt und dadurch

wird die Ausführung des rufenden Threads nicht blockiert. Wenn die Methode keinen Rückgabewert hat leuchtet mir das sogar ein, aber was ist wenn ich mit der 

Rückgabe dieser Methode arbeiten muss? Ich müsste dann doch mit await auf die Methode warten und hätte damit nichts gewonnen oder?

 

 

Bearbeitet 25. Oktober 2021 von helicopta

[pr0gg3r]

vor einer Stunde schrieb helicopta:

wird die Ausführung des rufenden Threads nicht blockiert. Wenn die Methode keinen Rückgabewert hat leuchtet mir das sogar ein, aber was ist wenn ich mit der 

Rückgabe dieser Methode arbeiten muss? Ich müsste dann doch mit await auf die Methode warten und hätte damit nichts gewonnen oder?

Du willst ja vielleicht auf die Daten warten. Stell dir vor, du machst einen User-Login und möchtest den User entweder weiter leiten oder aber du willst ihm einen Fehler anzeigen. Das heißt, du sendest das Login-Request an den Server und wartest, bis das Ergebnis vom Server da ist. Das Ergebnis kannst du dann auswerten und den User weiterleiten oder den Fehler anzeigen. Wenn du das Ergebnis noch nicht hast, was möchtest du machen? Immer weiterleiten, obwohl nicht evtl. falsche Zugangsdaten? Oder immer einen Fehler anzeigen? Das macht ja keinen Sinn...

Der Login ist nur ein Beispiel, man hat ganz oft Use-Cases bei denen man auf irgendetwas warten muss. Sei es eine Datenbankabfrage, das Convertieren von Daten, auf das Dateisystem warten, uvm.

[Whiz-zarD]

vor 12 Stunden schrieb pr0gg3r:

Du willst ja vielleicht auf die Daten warten. Stell dir vor, du machst einen User-Login und möchtest den User entweder weiter leiten oder aber du willst ihm einen Fehler anzeigen. Das heißt, du sendest das Login-Request an den Server und wartest, bis das Ergebnis vom Server da ist. Das Ergebnis kannst du dann auswerten und den User weiterleiten oder den Fehler anzeigen. Wenn du das Ergebnis noch nicht hast, was möchtest du machen? Immer weiterleiten, obwohl nicht evtl. falsche Zugangsdaten? Oder immer einen Fehler anzeigen? Das macht ja keinen Sinn...

Der Login ist nur ein Beispiel, man hat ganz oft Use-Cases bei denen man auf irgendetwas warten muss. Sei es eine Datenbankabfrage, das Convertieren von Daten, auf das Dateisystem warten, uvm.

Und was hat das mit async/await zu tun?

Zur Klarstellung: Async-Methoden laufen nicht in einem eigenen Thread. Sie laufen im selben Thread aber sie blockieren nicht den Thread, da sie im sog. Sychronisierungskontext des Threads verwaltet werden. Ich stecke da nicht ganz so tief drinnen aber es möglich, dass im Sychronisierungskontext tatsächlich ein Threadpool bereitgestellt wird. Aber wie gesagt, da stecke ich nicht so tief drinnen und wäre auch nur gefährliches Halbwissen von mir.

Ein Vorteil von async/await hast du schon genannt: Der aktuelle Thread wird nicht blockiert. Grafische Oberflächen (UI) laufen in einem sog. UI-Thread. D.h. die UI darf nur in einem einzigen Thread geändert werden. UIs laufen in einer Endlosschleife und sie werden immer wieder neu gezeichnet. Das heißt aber auch, dass der UI-Thread nicht blockiert werden darf. Wenn du aber eine Logik ausführst, die etwas länger dauert, dann wird der UI-Thread blockiert und die UI kann nicht mehr reagieren. Das bedeutet auch, dass du z.B. keine Progressbar anzeigen lassen kannst und Windows würde auch melden, dass die Anwendung nicht mehr reagiert. Du hättest auch nicht die Möglichkeit z.B. einen Abbrechen-Button zu implementieren, weil der Event des Buttons erst aufgerufen werden kann, wenn deine Logik durchgelaufen ist und die UI wieder reagieren kann. Mit async/await würdest du diese Logik, wie du schon sagst, in einen separaten Bereich auslagern, um den UI-Thread nicht zu blockieren.

Ein anderes Beispiel wäre ein asynchrones Logging, um z.B. nicht auf die Festplatte zu warten, bis die Meldung endlich in die Datei geschrieben wurde.

Ein weiterer Vorteil wäre, dass du z.B. mehrere Tasks gleichzeitig ausführen kannst. z.B. die Methode Task.WaitAll() nimmt ein Array von Task entgegen, die alle gleichzeitig gestartet werden können. z.B. möchtest du vielleicht ein Dashboard entwickeln, auf dem mehrere Kennzahlen darstellt werden soll. Mit Async/Await könntest du dafür sorgen, dass alle Kennzahlen gleichzeitig ermittelt werden und nicht jede einzelne sequentiell. Klar, kann man das auch alles mit Backgroundworkern bauen aber async/await nimmt einem sehr viel Arbeit ab. Zumal Backgroundworker tatsächlich einzelne Threads erstellen.

[KeeperOfCoffee]

Ich würde empfehlen die Asynchronous programming patterns zu lernen die .NET unterstützt bzw. vor allem das TAP lernen, da es das empfohlene/übliche Pattern ist.

https://docs.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/

vor 16 Stunden schrieb helicopta:

Rückgabe dieser Methode arbeiten muss? Ich müsste dann doch mit await auf die Methode warten und hätte damit nichts gewonnen oder?

HIer musst du eben entscheiden, ob es nicht sinnvoller ist gleich mit einer synchroner Methode zu arbeiten. Wenn an einer gezielten Stelle "nichts weitergehen kann" weil du z.B. ein Zwischenergebnis brauchst, dann wäre asynchrone Programmierung hier evtl. fehl am Platz. Du müsstest schließlich hier auf das Ergebnis warten bzw. dir das Result des Tasks ansehen.

 

Das schöne ist halt, dass du nichts "abarbeitest" sondern viele Dinge gleichzeitig machen kannst. Das ist praktisch bei einer recht großen UI die mit vielen Daten gefüttert wird. Stell dir vor du musst in einem Fenster große Datenmengen nacheinander abholen und der UI wäre blockiert...

Auch hast du die Freiheit Tasks zu canceln, falls etwas schief geht => https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/task-cancellation

 

Meine Empfehlung wäre: Such dir mal ne offene API (https://github.com/public-apis/public-apis) und spiele damit rum. Gerade wenn du eine Anwendung erstellst, die mit einer API kommuniziert, setzt du auf asnychrone Programmierung.

Ein Beispiel: Deine Anwendung zeigt dem User nebenbei noch das Wetter an, welches du von einer Wetter-API bekommst. Jetzt soll natürlich nicht ständig die UI blockiert werden, wenn das Wetter abgerufen wird. Das Ding soll so nebenbei laufen. Auch soll die App nicht abstürtzen, wenn die Wetter-API Probleme hat. Ist ja nicht deine Baustelle. Du willst also asynchron mit der API kommunizieren. Wenn du Daten bekommst => super, wenn nicht => App läuft weiter und schmiert nicht ab.