Asynchroniczność nie jest nowym tematem. Istnieje z nami od lat. Z czasem wiele się zmieniło w podejściu do niej. Współczesne języki programowania znacząco ułatwiają posługiwanie się nią. Dla C# jedną z najważniejszych zmian było wprowadzenie słów kluczowych async i await. Od tego momentu asynchroniczność jest bardzo powszechnie wykorzystywana w projektach .Net. Jednak ta łatwość bywa zwodnicza. Można napisać kod działający przez większość czasu, ale sporadycznie generujący trudne do zdiagnozowania błędy. Dzięki lekturze tego tekstu dowiesz się, dlaczego warto korzystać z async/await. Przyjrzymy się też jednemu z częściej popełnianych błędów przy pisaniu asynchronicznego kodu. Co pozwoli Ci uniknąć przykrych niespodzianek przy pracy i żmudnego debugowania aplikacji. A zaoszczędzony czas zawsze można spożytkować na coś przyjemniejszego.
Po co stosować async/await?
Większość programistów zaczyna przygodę z kodem, pisząc aplikacje synchroniczne. W skrócie oznacza to, że każda kolejna linijka kodu jest wykonywana po zakończeniu poprzedniej. Niewątpliwą zaletą tego rozwiązania jest prostota. Taki kod jest dużo łatwiej czytać i analizować, ale jak to w życiu bywa, zawsze jest coś, za coś. W tym przypadku po drugiej stronie wagi znajduje się wydajność aplikacji. Pisząc kod asynchroniczny, można dużo zyskać w tym temacie. Sprowadzając to do prostego życiowego przykładu - chcemy zrobić śniadanie. W synchronicznym świecie zaczęlibyśmy od zaparzenia kawy, następnie przygotowania kanapek. Przy bliższym spojrzeniu na proces okazuje się, że sporo czasu zajęło oczekiwanie, aż zagotuje się woda na małą czarną. Dzięki asynchroniczności można wykorzystać ten czas na wykonanie innych zadań. W powyższym przykładzie: na robienie kanapek. W świecie programowania analogicznie można wykorzystać oczekiwania na pobranie pliku, czy wykonanie skomplikowanego zapytania do bazy danych. Bardzo prosty kod z wykorzystaniem wspomnianych narzędzi wygląda tak:
1 public static async Task Main(string[] args) 2 { 3 await Task.Delay(500); 4 System.Console.WriteLine("Hello, async world!"); 5 }
Dwie najważniejsze rzeczy do zaobserwowania to:
- Async w sygnaturze metody Main. W ten sposób kompilator dostaje informację, że metoda może być wykonywana asynchronicznie.
- Await. Od tego momentu dzieje się magia. Kod może być wykonany równolegle. Oczywiście w powyższym przykładzie niewiele się dzieje, jest tylko oczekiwanie 500 ms. A co za tym idzie, czas wykonania kodu to około 500 ms. Póki co żadnej magii nie widać, chociaż kryje się pod spodem. Dlatego warto przejść do trochę bardziej rozbudowanego przykładu.
1 public static async Task Main(string[] args) 2 { 3 var stopWatch = new Stopwatch(); 4 stopWatch.Start(); 5 var delay1 = Task.Delay(500); 6 var delay2 = Task.Delay(500); 7 await Task.WhenAll(delay1, delay2); 8 stopWatch.Stop(); 9 System.Console.WriteLine($"Hello, async world! Time: {stopWatch.ElapsedMilliseconds} ms"); 10 }
Na pierwszy rzut oka nic wielkiego. Task.Delay(500) jest wywoływany dwa razy. Wniosek jest prosty. Czas wykonania całego kodu powinien wynosić nieco ponad sekundę. Cytując klasyka - nic bardziej mylnego. Wątpliwości może rozwiać uruchomienie kodu i odczytanie czasu zarejestrowanego za pomocą klasy Stopwatch. Dlaczego Stopwatch, a nie zwykły DateTime.Now? To już temat na inny artykuł. Wracając do tematu:
1Hello, async world! Time: 588 ms
Wynik to 588 ms. Polecenia Task.Delay(500) zostały wykonane równolegle. A za pomocą await Task.WhenAll(delay1, delay2) program oczekuje, aż te zadania się zakończą. W powyższych kodach występuje cichy bohater skrzętnie do tej pory pomijany. Jest to klasa Task. To właśnie połączenie klasy Task oraz słów kluczowych async, await daje kontrolę nad asynchronicznością. Tutaj też pojawia się pierwsza pułapka. Od czasu do czasu można spotkać w kodach aplikacji funkcję o następującej sygnaturze: async void DoSomethingAsync(...)
Dlaczego async void to zło konieczne?
Jest takie popularne powiedzenie. Jeśli nie wiadomo, o co chodzi, to chodzi o pieniądze. W tym przypadku chodzi o kompatybilność wsteczną, ale koniec końców z biznesowego punktu widzenia ten temat w projektach informatycznych też sprowadza się do pieniędzy. Składni async void należy unikać, kiedy tylko się da. Jej użycie rodzi pewne konsekwencje. Tylko w przypadku, gdy znamy konsekwencje naszych czynów, możemy świadomie decydować, czy chcemy je podjąć. Dlatego każde zauważenie przez programistę async void w kodzie aplikacji powinno triggerować event „Czy to na pewno dobry pomysł?” oraz „Co autor kodu miał na myśli?”. A skoro mowa o eventach… To właśnie tam async void ma swoje naturalne środowisko do życia. Dokładniej, w event handler’ach. Event handler musi pasować do sygnatury delegatu danego event’a, np.: public delegate void EventHandler(object sender, EventArgs e);
Sygnatura jest prosta i jasna. W tym miejscu nie można użyć wspomnianego wcześniej Task sprowadzając delegat do następującej formy: public delegate Task EventHandler(object sender, EventArgs e);
Niestety ta sygnatura nie pasuje do eventów wykorzystywanych powszechnie w C#. Dla osób pracujących na co dzień z bibliotekami WinForms, czy WPF będzie to chleb powszedni. Wszelkie próby użycia async Task np. przy podpinaniu akcji kliknięcia button’a są skazane na niepowodzenie zwieńczone błędami kompilacji. Podsumowując async void ma swoje zastosowanie w event handlerach. Użycie tej składni w innych miejscach to bardzo kiepski pomysł. Zapewne nasuwa się teraz pytanie dlaczego?
Odpowiedź wbrew pozorom jest dość logiczna. W celu wykonania await na danej metodzie potrzebujemy obiektu Task. EventHandler’y ze swojej natury nie zwracają nic. Używając składni async void w innych sytuacjach niż ta wcześniej wspomniana sami narzucamy sobie niepotrzebne ograniczenie. A brak możliwości wykonania await na metodzie niesie za sobą pewne konsekwencje. Pierwsza to rozpoczęcie wykonywania danej metody bez oczekiwania na jej zakończenie.
1 public static async Task Main(string[] args) 2 { 3 System.Console.WriteLine("App started"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 System.Console.WriteLine("Delay1 started"); 7 var delay1 = Task.Delay(500); 8 LongBackgroundJob(); 9 System.Console.WriteLine("Delay2 started"); 10 var delay2 = Task.Delay(500); 11 await Task.WhenAll(delay1, delay2); 12 stopWatch.Stop(); 13 System.Console.WriteLine($"Hello, async world! Time: {stopWatch.ElapsedMilliseconds} ms"); 14 } 15 16 public static async void LongBackgroundJob() 17 { 18 System.Console.WriteLine("LongBackgroundJob started"); 19 await Task.Delay(500); 20 System.Console.WriteLine("LongBackgroundJob finished"); 21 }
Efektem wykonania powyższego kodu jest następująca odpowiedź w konsoli:
1App started 2Delay1 started 3LongBackgroundJob started 4Delay2 started 5LongBackgroundJob finished 6Hello, async world! Time: 525 ms
Metoda LongBackgroundJob została uruchomiona równolegle z pozostałym kodem. Na pierwszy rzut oka nie dzieje się nic strasznego. Podobnie jest z taskami delay1 oraz delay2. Tylko że w przypadku wspomnianych tasków można wykonać await - patrz linia nr 18, w powyższym fragmencie kodu. Próba wykonania await na metodzie LongBackgroundJob zakończy się błędem kompilacji:
Wychodzi na to, że kończymy z wywołaniem typu “odpal i zapomnij”. Nie zawsze to musi być złe, ale takie zabiegi powinny być wykonywane w pełni świadomie. W innym przypadku mogą prowadzić do bardzo trudnych do zdiagnozowania błędów w logice aplikacji, np. korupcji danych, lub po prostu zawieszania aplikacji. W drugim przypadku async void będzia miał również swoje dwa grosze. W sytuacji wystąpienia exception’a proces po prostu zakończy swoje działanie. Takiego efektu nie zaobserwujemy w przypadku użycia async Task. Można powiedzieć wielka rzecz… Exception wyłożył aplikację. Poniższy kod generuje exception podczas wykonywania metody LongBackgroundJob:
1 public static async Task Main(string[] args) 2 { 3 System.Console.WriteLine("App started"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 System.Console.WriteLine("Delay1 started"); 7 var delay1 = Task.Delay(500); 8 LongBackgroundJob(); 9 System.Console.WriteLine("Delay2 started"); 10 var delay2 = Task.Delay(500); 11 await Task.WhenAll(delay1, delay2); 12 stopWatch.Stop(); 13 System.Console.WriteLine($"Hello, async world! Time: {stopWatch.ElapsedMilliseconds} ms"); 14 } 15 16 public static async void LongBackgroundJob() 17 { 18 System.Console.WriteLine("LongBackgroundJob started"); 19 await Task.Delay(100); 20 throw new Exception("Exception from LongBackgroundJob"); 21 System.Console.WriteLine("LongBackgroundJob finished"); 22 } 23}
Magia zaczyna się, gdy postanowimy otoczyć kapryśną metodę przy użyciu bloku try...catch:
1 public static async Task Main(string[] args) 2 { 3 System.Console.WriteLine("App started"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 System.Console.WriteLine("Delay1 started"); 7 var delay1 = Task.Delay(500); 8 try 9 { 10 LongBackgroundJob(); 11 } 12 catch(Exception) 13 { 14 System.Console.WriteLine("Exception from LongBackgroundJob catched"); 15 } 16 System.Console.WriteLine("Delay2 started"); 17 var delay2 = Task.Delay(500); 18 await Task.WhenAll(delay1, delay2); 19 stopWatch.Stop(); 20 System.Console.WriteLine($"Hello, async world! Time: {stopWatch.ElapsedMilliseconds} ms"); 21 } 22 23 public static async void LongBackgroundJob() 24 { 25 System.Console.WriteLine("LongBackgroundJob started"); 26 await Task.Delay(100); 27 throw new Exception("Exception from LongBackgroundJob"); 28 System.Console.WriteLine("LongBackgroundJob finished"); 29 } 30}
Można oczekiwać, że exception zostanie wyłapany i aplikacja będzie kontynuowała wykonywanie. Nic bardziej mylnego:
1App started 2Delay1 started 3LongBackgroundJob started 4Delay2 started 5Unhandled exception. System.Exception: Exception from LongBackgroundJob 6 at DemoConsoleApp.Program.LongBackgroundJob() in C:\Users\rafal\source\repos\rafalswirk\CommonAsyncMistakes\DemoConsoleApp\Program.cs:line 34 7 at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state) 8 at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
Ponownie exception zabija aplikację. Powyższy przykład jest trywialny. To tylko parę linii kodu. Mamy zapięte środowisko programistyczne. W przypadku dużych aplikacji legacy, gdzie pojedyncza klasa potrafi mieć kilkanaście tysięcy linii kodu, dodatkowo działających na maszynach użytkownika końcowego, bez możliwości uruchomienia wszystkiego z VisualStudio - wtedy już nie jest wesoło. Zwłaszcza jeśli błąd występuje od czasu do czasu i nie ma jasnych kroków jego odtworzenia. Jak zatem złapać taki exception? Blok try-catch wystarczy umieścić wewnątrz nieszczęsnej metody:
1 public static async Task Main(string[] args) 2 { 3 System.Console.WriteLine("App started"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 System.Console.WriteLine("Delay1 started"); 7 var delay1 = Task.Delay(500); 8 LongBackgroundJob(); 9 System.Console.WriteLine("Delay2 started"); 10 var delay2 = Task.Delay(500); 11 await Task.WhenAll(delay1, delay2); 12 stopWatch.Stop(); 13 System.Console.WriteLine($"Hello, async world! Time: {stopWatch.ElapsedMilliseconds} ms"); 14 } 15 16 public static async void LongBackgroundJob() 17 { 18 try 19 { 20 System.Console.WriteLine("LongBackgroundJob started"); 21 await Task.Delay(100); 22 throw new Exception("Exception from LongBackgroundJob"); 23 System.Console.WriteLine("LongBackgroundJob finished"); 24 }
Wywołanie powyższego kodu będzie trochę bardziej przewidywalne:
1Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.7\System.Text.Encoding.Extensions.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. 2App started 3Delay1 started 4LongBackgroundJob started 5Delay2 started 6Exception thrown: 'System.Exception' in DemoConsoleApp.dll 7Exception from LongBackgroundJob catched 8Hello, async world! Time: 543 ms 9The program '[4024] DemoConsoleApp.dll' has exited with code 0 (0x0).
Podsumowanie
Async i await znacząco ułatwiają pracę z kodem wielowątkowym. O ile w większości przypadków użycie tego mechanizmu jest jasne, to część programistów wpada w pułapkę użycia async void. Dobrą praktyką jest unikanie tej konstrukcji, kiedy tylko się da. Jedyne miejsce, gdzie znajduje zastosowanie to event handlery, ale nawet w tym przypadku bardzo łatwo o napisanie kodu generującego dość niespodziewane zachowania.
