Nisam koristio TPL tako da ne mogu da pravim nekakve konkretne paralele sa async/await,
mada, koliko vidim, TPL i async/await se ne bave i ne rešavaju iste stvari.


Nije nužno u drugom thread-u - može a i ne mora, zavisi od implementacije task-a.

Asinhroni task je obećanje da će nešto da se završi u budućnosti.
Kada se to desi, nastavlja se tamo gde se stalo, tj. posle await-a.

Umesto da se piše kod sa callback-ovima koji je jako nezgodono pratiti,
piše se klasičan top-down kod čiji se delovi efektivno izvršavaju asinhrono.

Ok hvala na odgovoru.
Slazem se sa tobom i da je lakse pratiti kod jer se nastavlja izvrsavanje nakon awaita.
Meni je doduse mnogo lakse sa Task i zatim sa Task.ContinueWith() da tacno iskontrolisem sta se izvrsava gde i u kom trenutku.
Onda ulancam Taskove i preskacem iz UI threada u background thread, i obrnuto.
Sada koliko vidim to se zapravo skriva i apstrahuje sa async/await zbog preglednosti (mada je meni i Task sam pregledan).
Kako da uradim Parallel.For sa async/await?

Treba samo napomenuti da await poziv async metoda NIJE asinhroni poziv. To je sinhroni poziv koji odlazi u async samo u specificnim situacijama (IO ili poziv druge vrste sistemskog blocking metoda). Jedini drugi nacin da svoj async metod "nateras" da ode u drugi thread je da pozoves Task.Yield();

U osnovi async/await je kompajlerska mahinacija sa Task.ContinueWith() (kad kazem odlazi u async samo u specificnim situacijama mislim ubaci ContinueWith() ) s tim sto postoji implicitno pracenje konteksta. Druga prednost je sto situacije u kojima imas puno kontinuacija, kad su napisane u a/a maniru mnogo lepse izgledaju.

Parallel.For sa druge strane je task dispatcher, njegova primena je najjaca u situacijama kad imas neko masovno procesiranje nad podacima koje mozes da particionises u nezavisne podsetove. Van toga je cisto silovanje.