Async / Await operator

[ magrinjo @ 19.01.2020. 17:05 ] @

Pozdrav svima,

Zeleo bih da ubrzam svoju demo aplikaciju uvodjenjem async/await metoda.

Pratio sam dokumentaciju ali nisam bas najsigurniji kako asinhrone metode funkcionisu na ovom primeru.

Code:

public async Task<bool> ProveriDaLiPostoji(){

var covek = await _podatak.Covek.DaLiPostoji();
var zivotinja = await _podatak.Zivotinja.DaLiPostoji();
var duh = _podatak.Duh.DaLiPostoji();

}

--

U ovom slucaju, iz tri promenjive dobijamo podatak iz Query modela koji se zove "_podatak". U tom modelu, metoda je isto await sem za "var duh".

Ono sto me buni jeste sta dobijam primenom async/await u ovom slucaju, gde mi samo promenjiva "duh" nije asinhrona?

[ dusans @ 19.01.2020. 20:25 ] @

U suštini, prostom upotrebom async/await ne dobijaš ubrzanje (ponekad dobijaš i dozu usporenja),
već oslobađaš thread koji može da radi nešto drugo (dakle nije blokiran) dok se čeka na završetak asinhronih operacija.

Ovo je poželjno kod, na primer, ASP.Net aplikacija pošto bolje skalira nego sinhroni kod -
smanjuje broj potrebnih thread-ova - jedan thread može da opslužuje više od jednog request-a.
https://www.red-gate.com/simpl...eature-in-promise-and-practice

Tvoj slučaj gde proveravaš postojanje nečega možeš zaista da ubrzaš tako što ćeš da pokreneš obe
Covek.DaLiPostoji() i Zivotinja.DaLiPostoji() i sačekaš na završetak koristeći Task.WaitAll(...)
Otprilike ovako:

Code:

var covekTask = _podatak.Covek.DaLiPostoji();
var zivotinjaTask = _podatak.Zivotinja.DaLiPostoji();

await Task.WaitAll(covekTask, zivotinjaTask);

var nestoPostoji = covekTask.Result || zivotinjaTask.Result || ...;

Dakle, ne ideš sekvencijalno jednu po jednu operaciju sa await (pošto su nezavisne jedna od druge),
već ih pokreneš sve (nazovi "paralelno") i onda čekaš (await) dok se sve ne završe.

_{[Ovu poruku je menjao dusans dana 19.01.2020. u 21:41 GMT+1]}

[ magrinjo @ 23.01.2020. 17:35 ] @

Hvala na odgovoru :)

[ mmix @ 31.01.2020. 06:41 ] @

Ja samo da dodam da je async/await zapravo nastao i ima vecu korist zbog desktop aplikacija (winforms i wpf). Njegova prvobitna namena je bila da oslobodi glavni GUI thread od cekanja na hendlere.
ASP.NET je samo preuzeo koncept, i uglavnim ignorise ExecutionContext i kad se ne napise dobro zapravo pravi vise stete nego da ste pustili da se request obavi u jednom threadu, pa je upotreba ConfigureAwait veoma pozeljna.

U principu gornji primer bi trebalo da izgleda ovako ako je handler za win/wpf. Asp.net bi u principu sve trebalo da fura na false:

Code (csharp):

var covekTask = _podatak.Covek.DaLiPostoji().ConfigureAwait(false); // ne interesuje nas da se task nastavi u istom kontekstu

var zivotinjaTask = _podatak.Zivotinja.DaLiPostoji().ConfigureAwait(false);

await Task.WaitAll(covekTask, zivotinjaTask).ConfigureAwait(true);   // nas krajnji rezultat zelimo u glavnom kontestu, asp.net moze i false.

var nestoPostoji = covekTask.Result || zivotinjaTask.Result || ...;