En otras palabras, es
var task = SomeLongRunningOperationAsync(); task.Wait();funcionalmente idéntico a
SomeLongRunningOperation();Dicho de otra manera, es
var task = SomeOtherLongRunningOperationAsync(); var result = task.Result;funcionalmente idéntico a
var result = SomeOtherLongRunningOperation(); De acuerdo con Wait e Inlining , si la tarea en la que se está esperando ya ha comenzado a ejecutarse, Wait tiene que bloquearse. Sin embargo, si no ha comenzado a ejecutarse, Wait puede extraer la tarea de destino del programador en el que se puso en cola y ejecutarla en línea en el subproceso actual.
¿Son esos dos casos simplemente una cuestión de decidir en qué subproceso se ejecutará la Tarea, y si está esperando el resultado de todos modos, importa?
¿Hay algún beneficio en usar el formulario asíncrono sobre el formulario síncrono, si no se ejecuta nada entre la llamada asíncrona y Wait() ?
Aquí hay algunas diferencias:
AggregateException . La pila de excepciones será diferente.HttpContext.Current (que en realidad no es local del subproceso, pero casi), puede ser diferente.Task genera una barrera de memoria que puede tener un efecto de sincronización.¿Importa esto? Decida usted mismo por esta lista.
¿Hay beneficios al hacer esto? No puedo pensar en ninguno. Si su cálculo utiliza E/S asíncrona, la espera anulará los beneficios que aporta la E/S asíncrona. La única excepción sería la E/S de abanico, por ejemplo, emitiendo 10 solicitudes HTTP en paralelo y esperándolas. De esa manera, tiene 10 operaciones al costo de un hilo.
Tenga en cuenta que Wait y Result son equivalentes en todos estos aspectos.