C# versione 5 rende l'utilizzo della programmazione asincrona piuttosto agevole attraverso l'utilizzo di un pattern molto semplice e di due keyword:
async e
await.
Utilizzare codice "asincrono" è una necessità non solo quando si vuole parallelizzare l'esecuzione di procedure, ma anche quando si vuole rendere la logica di business indipendente dal codice che gestisce e muove l'interfaccia grafica. L'idea è che nessuna operazione debba "stoppare" l'esecuzione del codice deputato a gestire l'input dell'utente o a fornirgli un feedback.
Tanto più urgente è questa necessità quanto più il device ha processori poco potenti: che è il caso tipico dei device mobile. Ad esempio, il framework di programmazione di Windows Phone, WinRT, si basa pesantemente sul concetto di programmazione asincrona, ed il suo uso è obbligatorio. Non è possibile, giusto per citare un caso, in
WinRT, leggere un file in sincrono: è invece necessario predisporre il codice asincrono, in modo che mentre le operazioni di lettura del file sono in esecuzione, l'interfaccia e il resto del programma continuano a funzionare in parallelo.
La gestione della programmazione asincrona, benché semplice, è piuttosto controintuitiva. Su MSDN si legge che "
l'operatore await dice al compilatore che il metodo marcato async non può continuare dopo quel punto fino a che il processo asincrono che si aspetta non è terminato". Cerchiamo di capire cosa significa con un esempio.
Supponiamo di avere una ipotetica funzione di business che ci impiega molto tempo per completare. Ad esempio questa, che su un portatile non troppo vecchio impiega qualche secondo:
static long LongRunningComputation(int i)
{
Random cycleSeed = new Random();
long result = 0; int rnd = 0;
for (long j = 0; j < cycleSeed.Next() * 1E5 + 3E6; j++)
{
rnd = cycleSeed.Next(11);
result += (rnd % 2 == 0) ? rnd : -rnd;
}
return result;
}
La prima cosa che occorre fare è incapsulare questa funzionalità in un metodo asincrono. Ogni metodo asincrono è tale se ritorna un oggetto
Task. Un oggetto
Task si costruisce con una
Factory che si chiama
Task.Run e prende in input
una funzione lambda qualsiasi, con questa sintassi:
static async Task LongTaskAsync(int i)
{
Task longOperation =
Task.Run(() > LongRunningComputation(i));
return await longOperation;
}
La prima istruzione serve per costruire l'oggetto
Task. Questo è un oggetto che mantiene lo stato e le informazioni sul processo asincrono che è in corso. Il fatto che la nostra operazione ritorni un intero viene riflesso nel fatto che Task è di fatto un contenitore generico (di un intero lungo).
La funzione
lambda è in grado di "leggere" i parametri che sono in scope nel momento in cui è definita, quindi non c'è bisogno di specificare che intendiamo passargli l'intero "i" -
questa cosa io ci ho messo francamente un po' per capirla... io avrei messo
((i) => LongRunningComputation(i))
però il parametro di Task.Run è un delegato che non accetta parametri!
La norma vuole che ogni funzione "asincrona" abbia un nome che termina in "Async" e non ci adeguiamo. La parola "await" significa che questo metodo deve aspettare il termine dell'operazione "
LongRunningComputation" prima di tornare un valore che abbia senso! Infatti il codice
LongRunningComputation viene lanciato in asincrono, e quindi la linea di codice successiva viene eseguita immediatamente.
Senza la programmazione asincrona, si potrebbe pensare di costruire una funzione che esegue due chiamate all'operazione lunga e somma i loro risultati, così:
static long GoInLineNormally()
{
Console.WriteLine("Going in sequence, normally");
long x1 = LongRunningComputation(11);
Console.WriteLine("X1 (NORMAL) = " + x1);
long x2 = LongRunningComputation(22);
Console.WriteLine("X2 (NORMAL) = " + x2);
return (x1 + x2);
}
Siccome abbiamo detto che l'operazione lunga ci mette grossomodo due secondi, la procedura di cui sopra ci metterebbe circa quattro secondi per essere eseguita.
Ma abbiamo la programmazione asincrona, e quindi è lecito pensare che le due possano essere lanciate sue due
thread differenti, e quando ciascun
thread esce con un risultato, sommarli e stamparli a video.
static async Task GoInParallelAsync()
{
Console.WriteLine("Going in parallel");
var t1 = LongTaskAsync(11);
var t2 = LongTaskAsync(22);
await Task.WhenAll(t1, t2);
Console.WriteLine("X1 (PARALLEL) = " + t1.Result);
Console.WriteLine("X2 (PARALLEL) = " + t2.Result);
return (t1.Result + t2.Result);
}
Per farlo abbiamo lanciato
LongTaskAsync e poi, attraverso la funzione
Task.WhenAll, abbiamo "aspettato" che entrambi finissero per raccogliere i risultati. L'esecuzione totale, come ci aspettavamo è di circa due secondi invece che quattro.
Ricapitolando. Se un metodo asincrono viene lanciato con l'operatore "await", l'esecuzione si ferma finché il metodo non ha ritornato un risultato - ma questo metodo viene comunque lanciato su un thread differente rispetto al programma che lo ha lanciato, il quale può ad esempio continuare così ad aggiornare l'interfaccia grafica e a rimanere in ascolto di eventuali eventi. Se invece un metodo asincrono viene lanciato senza l'operatore await, la linea successiva di codice viene eseguita immediatamente, e il controllo sull'esecuzione del task asincrono è demandato ai metodi della classe
Task.
Infatti, se lanciamo con:
static async Task GoInLineAsync()
{
Console.WriteLine("Going in sequence, but async");
long x1 = await LongTaskAsync(11);
Console.WriteLine("X1 (SEQUENCE) = " + x1);
long x2 = await LongTaskAsync(22);
Console.WriteLine("X2 (SEQUENCE) = " + x2);
return (x1 + x2);
}
il codice esegue prima
LongTaskAsync(11) e solamente dopo aver ottenuto il risultato (ciò che è espresso dall'operatore await), lancia il
LongTaskAsync(22).
Questo codice, benché funzionalmente identico a
GoInLineNormally è molto diverso dal punto di vista del comportamento! Il primo infatti è rigorosamente sincrono: ogni linea di codice viene eseguita solo e soltanto se quella precendente è terminata. Il secondo, invece, attraverso l'operatore "await" dice al compilatore: adesso esegui in asincrono su un thread differente
LongTaskAsync, e aspetta che il metodo asincrono sia terminato prima di proseguire con la prossima linea di codice.
E' da notare in particolare il codice
entry point, Main, che richiama le procedure scritte sopra:
static void Main(string[] args)
{
Console.WriteLine("AYNC/AWAIT TEST v.1.0");
Console.WriteLine();
//long r = GoInLineNormally();
var t = GoInLineAsync();
//var t = GoInParallelAsync();
Console.WriteLine("END TEST (Is it really ended?)");
Console.WriteLine("Result = " + t.Result);
Console.WriteLine();
Console.ReadKey();
}
Domanda: quando viene stampata la linea "END TEST"?
Alla fine dell'esecuzione dei vari metodi
GoIn...? La risposta è sì, se si tratta di
GoInLineNormally(), ma è no in entrambi gli altri casi: si tratta di metodi asincroni che ritornano subito (non c'è
await)! Quindi "END TEST" non è proprio un messaggio di End, perché viene stampato immediatamente, mentre i metodi asincroni sono in esecuzione. Viceversa, "
Result =" viene stampato effettivamente alla fine dei calcoli, perché il valore di t è "awaited" da
t.Result.
E se avessimo voluto "aspettare" l'esecuzione GoInLineAsync() prima di scrivere "END"? Non avremmo potuto farlo! Infatti un metodo che contiene una chiamata "await" deve per forza essere marcato "async". Ma il metodo Main non può essere "async"! Quindi non abbiamo potuto scrivere, per esempio:
var t = await GoInLineAsync()
Se avessimo marcato il metodo Main come "async", avremmo detto al compilatore che quel metodo va eseguito in asincrono e che deve ritornare immediatamente al chiamante, per poi "rientrare" quando il metodo sia terminato: due cose che un programma a console, evidentemente, non può fare.
