Kiedy stosować asynchroniczność

Cześć, możliwe, że zadam pytanie na poziomie wczesnego juniora, ale wciąż zastanawia mnie jedna rzecz. W których przypadkach używać metod i akcji asynchronicznych?

Aktualnie w projekcie w którym pracuje wszystkie repozytoria są napisane synchronicznie, zastanawia mnie czy nie powinno być to zmienione tak by nie blokować wątku gdy odpytujemy się o jakiś zasób źródło zewnętrzne. Po wczytaniu się w parę kursów i poradników doszedłem do wniosku, że można używać tego praktycznie wszędzie tak by nie blokować połączeń z systemem lub bazą danych. Czy jest faktycznie sens używania asynchronicznych akcji i co za tym idzie metod wszędzie za każdym razem gdy coś zmieniamy w bazie?

Świetnie byłoby gdyby ktoś dał jakiś przykład kiedy nie, a kiedy tak :)

Zawsze.

Gdy aplikacja może robić różne rzeczy, a jedna operacja zajmuje dużo czasu, to gdy uruchomisz ją synchronicznie w wątku głównym, to dopóki nie zostanie ona ukończona, program przestanie reagować, co jest dość wkurzające.

Jak sam zauważyłeś synchroniczne odwoływanie się do I/O blokuje nam wątek, a liczba wątków którą dany serwer jest w stanie obsłużyć jest ograniczona.
Także w aplikacjach webowych używa się asynchronicznych odwołań do I/O po to by móc obsłużyć więcej requestów w danej sekundzie czasu.
Jeśli przepustowość nie jest problemem danej aplikacji to równie dobrze wszystko można pisać synchronicznie.
Jeśli chodzi o pojedyncze przypadki (jeśli ktoś chciałby się rozdrabniać) kiedy stosować asynchroniczność, to jest to bardzo proste bo jest to liniowo zależne od czasu wykonania danego odwołania do I/O, im dłużej trwa dane wywołanie tym większy pożytek z użycia asynchroniczności.

Czyli prowadzi nas to do wniosku, że powinniśmy pisać zdecydowaną większość akcji jako aync ze względu, że praktycznie większość wyciąga jakieś dane z bazy i wyświetla je czy modyfikuje (szczególnie jeśli chodzi o modyfikowanie). No chyba ze mamy jakiś naprawdę mocny serwer który jest w stanie obsłużyć naprawdę dużo wątków na raz lub wiemy że apka będzie użytkowana przez małą grupę użytkowników. Chciałbym się upewnić.

Aplikacja nie powinna mieć więcej wątków niż procesor komputera

Skromny Kaczor napisał(a):

Aplikacja nie powinna mieć więcej wątków niż procesor komputera

A jaką część komputera ma procesor? Albo też - ile wątków ma procesor? ;-) Raczej "więcej wątków niż komputer procesorów/rdzeni".

Tak czy inaczej jest to dość kontrowersyjne stwierdzenie w kontekście tego, że większość wątków zwykle czeka na zakończenie operacji I/O. Napisałbym tak: aplikacja nie może mieć więcej aktywnych wątków niż komputer rdzeni - jednakże nie wiadomo, kiedy i jak długo dany wątek będzie czekać na zakończenie operacji I/O, więc warto mieć pewien nadmiar wątków czekających na wolne cykle CPU. Ile to ten "pewien nadmiar" ciężko jest określić, bo im więcej nadmiarowych wątków, tym więcej czasu CPU traci na przełączanie kontekstu, im mniej wątków, tym większa szansa na marnowanie cykli CPU przez brak wątków do wykonania. Z dwojga złego pewnie lepsze będzie zbyt dużo wątków (np. mój komputer w tej chwii ma ich odpalonych prawie 3000, a działa całkiem płynnie).

Skromny Kaczor napisał(a):

Aplikacja nie powinna mieć więcej wątków niż procesor komputera

Powiedz to projektantom serwerów http :P
Taki IIS 7.5 jest domyślnie skonfigurowany do pracy z 100 wątkami na każdy rdzeń procesora.

Nie myl wątków procesora i wątków systemowych - Windows czy linux wspierają wiele wątków i nie ograniczają się przy tym do ilości wątków procesora.

Slepiec napisał(a):

Skromny Kaczor napisał(a):

Aplikacja nie powinna mieć więcej wątków niż procesor komputera

Powiedz to projektantom serwerów http :P
Taki IIS 7.5 jest domyślnie skonfigurowany do pracy z 100 wątkami na każdy rdzeń procesora.

Nie myl wątków procesora i wątków systemowych - Windows czy linux wspierają wiele wątków i nie ograniczają się przy tym do ilości wątków procesora.

Słyszałeś o nieblokującym IO i o tym że 4wątkowy serwer może obsłużyć dziesiątki tysięcy requestów na raz ? jak inaczej chcesz rozwiązać c10k ?

Ja uważam że wątki programowe mają dużo wspólnego z ilością rdzeni i wątków procesora.
Wiem, że komputer może jednocześnie obsługiwać 100 lub więcej procesów, wątków ,
Mi chodziło o to że jeśli komputer ma 2 rdzenie a ja do wykonania zadania użyję 4 wątków albo więcej w programie
to zadanie zostanie wykonane wolniej niż w programie który ma 2 wątki

Skromny Kaczor napisał(a):

Ja uważam że wątki programowe mają dużo wspólnego z ilością rdzeni i wątków procesora.
Wiem, że komputer może jednocześnie obsługiwać 100 lub więcej procesów, wątków ,
Mi chodziło o to że jeśli komputer ma 2 rdzenie a ja do wykonania zadania użyję 4 wątków albo więcej w programie
to zadanie zostanie wykonane wolniej niż w programie który ma 2 wątki

Chyba, po cichu zakładasz, że zadanie, które rozwiązujesz na wielu wątkach jest praktycznie CPU-bound ;-)

Skromny Kaczor napisał(a):

Ja uważam że wątki programowe mają dużo wspólnego z ilością rdzeni i wątków procesora.
Wiem, że komputer może jednocześnie obsługiwać 100 lub więcej procesów, wątków ,
Mi chodziło o to że jeśli komputer ma 2 rdzenie a ja do wykonania zadania użyję 4 wątków albo więcej w programie
to zadanie zostanie wykonane wolniej niż w programie który ma 2 wątki

Spoko masz racje, ale tym się zajmuje system operacyjny żeby odpowiednio te wątki ułożyć. Jest to ważna ale nie aż tak.
Co to są 4 wątki, rzuć okiem na Manager Zadań z windowsa się okaże że Visual Studio używa około 90 wątków, Firefox jakieś 200 wątków, Excel ponad 40 wątków.

Ale wracając do C# i async. Async używa Tasków a nie Threadów, a to nie jest tym samym. Task jest lżejszy i dalej mu do faktycznych wątków procesora.