c# - sirve - Diferencia entre tarea y asíncrono.

task await c# ejemplo

Question

C # proporciona dos formas de crear métodos asíncronos:

Método 1:

static Task<string> MyAsyncTPL() {
Task<string> result = PerformWork();
return result.ContinueWith(t => MyContinuation());
}

Método 2:

static async Task<string> MyAsync() {
string result = await PerformWork();
return MyContinuation();
}

Ambos métodos anteriores son asíncronos y logran lo mismo. Entonces, ¿cuándo debo elegir un método sobre el otro? ¿Existen pautas o ventajas de usar una sobre la otra?

Answer 1

Te recomiendo que uses await lugar de ContinueWith . Si bien, en un nivel alto, son muy similares, también tienen un comportamiento predeterminado diferente.

Cuando utiliza ContinueWith , está eligiendo una abstracción de nivel inferior. En particular, aquí hay algunos "puntos de peligro", y es por esto que no recomiendo usar ContinueWith menos que el método sea realmente simple (o su nombre es Stephen Toub):

• Las excepciones surgidas de los métodos de async Task se colocan en la tarea devuelta; Las excepciones provocadas por métodos no async se propagan directamente.
• await por defecto reanudará el método async en el mismo "contexto". Este "contexto" es SynchronizationContext.Current menos que sea null , en cuyo caso es TaskScheduler.Current . Esto significa que si llama a MyAsync en un subproceso de UI (o dentro de un contexto de solicitud ASP.NET), MyContinuation también se ejecutará en el subproceso de UI (o en ese mismo contexto de solicitud ASP.NET). Explico esto más en mi blog .
• Siempre debe especificar un planificador para ContinueWith ; de lo contrario, recogerá TaskScheduler.Current , que puede causar un comportamiento sorprendente. Describo este problema en detalle en mi blog . Ese post es sobre StartNew ; pero ContinueWith tiene el mismo problema de "programador predeterminado no predeterminado" descrito en esa publicación.
• await utiliza el comportamiento apropiado y los indicadores de optimización que no están establecidos de forma predeterminada en ContinueWith . Por ejemplo, usa DenyChildAttach (para garantizar que las tareas asíncronas no se usen por error como tareas paralelas) y ExecuteSynchronously (una optimización).

En resumen, la única razón para usar ContinueWith para tareas asíncronas es ahorrar una cantidad extremadamente pequeña de tiempo y memoria (evitando la sobrecarga de la máquina de estado async ), y en cambio su código es menos legible y mantenible.

Con un ejemplo extremadamente simple, podría salirse con la suya; pero como señaló Jon Skeet, tan pronto como usted tiene bucles, el código de ContinueWith simplemente explota en complejidad.

Answer 2

await es básicamente una taquigrafía para la continuación, de forma predeterminada, utiliza el mismo contexto de sincronización para la continuación.

Para ejemplos muy simples como el suyo, no hay mucho beneficio en el uso de la await , aunque el ajuste y desenvolvimiento de las excepciones hace que el enfoque sea más consistente.

Sin embargo, cuando tienes un código más complicado, async hace una gran diferencia. Imagina que quisieras:

static async Task<List<string>> MyAsync() {
List<string> results = new List<string>();
// One at a time, but each asynchronously...
for (int i = 0; i < 10; i++) {
// Or use LINQ, with rather a lot of care :)
results.Add(await SomeMethodReturningString(i));
}
return results;
}

... eso se vuelve mucho más peludo con continuaciones manuales.

Además, async / await puede trabajar con tipos distintos a Task / Task<T> siempre que implementen el patrón apropiado.

Vale la pena leer más sobre lo que está haciendo detrás de escena. Es posible que desee comenzar con MSDN .