¿Eso no anula el propósito de descargar una tarea a un hilo sin esperar a que termine?

Sí, por supuesto. Pero ese no es el propósito de await/async . El propósito es permitirle escribir código síncrono que use operaciones asíncronas sin desperdiciar subprocesos o, de manera más general, dar a la persona que llama una medida de control sobre las operaciones más o menos asíncronas.

La idea básica es que siempre que use await y async correctamente, toda la operación parecerá ser sincrónica. Esto suele ser algo bueno, porque la mayoría de las cosas que hace son síncronas; por ejemplo, no desea crear un usuario antes de solicitar el nombre de usuario. Así que harías algo como esto:

 var name = await GetNameAsync(); var user = await RemoteService.CreateUserAsync(name);

Las dos operaciones son sincrónicas entre sí; el segundo no sucede (¡y no puede!) antes que el primero. Pero no son (necesariamente) sincrónicos con respecto a la persona que llama . Un ejemplo típico es una aplicación de Windows Forms. Imagine que tiene un botón y el controlador de clics contiene el código anterior: todo el código se ejecuta en el subproceso de la interfaz de usuario, pero al mismo tiempo, mientras await , el subproceso de la interfaz de usuario puede realizar otras tareas (similar a usar Application.DoEvents hasta que se complete la operación).

El código síncrono es más fácil de escribir y entender, por lo que le permite obtener la mayoría de los beneficios de las operaciones asíncronas sin hacer que su código sea más difícil de entender. Y no pierde la capacidad de hacer las cosas de forma asíncrona, ya que Task en sí es solo una promesa, y no siempre tiene que await de inmediato. Imagine que GetNameAsync lleva mucho tiempo, pero al mismo tiempo, tiene que hacer algo de trabajo de CPU antes de que termine:

 var nameTask = GetNameAsync(); for (int i = 0; i < 100; i++) Thread.Sleep(100); // Important busy-work! var name = await nameTask; var user = await RemoteService.CreateUserAsync(name);

Y ahora su código sigue siendo hermosamente sincrónico ( await es el punto de sincronización), mientras que puede hacer otras cosas en paralelo con las operaciones asincrónicas. Otro ejemplo típico sería disparar múltiples solicitudes asíncronas en paralelo pero manteniendo el código sincronizado con la finalización de todas las solicitudes:

 var tasks = urls.Select(i => httpClient.GetAsync(i)).ToArray(); await Task.WhenAll(tasks);

Las tareas son asincrónicas entre sí, pero no la persona que llama, que sigue siendo bellamente sincrónica.

He hecho una muestra de red (incompleta) que usa await de esta manera. La idea básica es que, si bien la mayor parte del código es lógicamente síncrono (hay un protocolo a seguir: solicitar inicio de sesión->verificar inicio de sesión->leer bucle...; incluso puede ver la parte donde se esperan múltiples tareas en paralelo) , solo usa un subproceso cuando realmente tiene trabajo de CPU que hacer. Await hace que esto sea casi trivial: hacer lo mismo con las continuaciones o el antiguo modelo asíncrono Begin/End sería mucho más doloroso, especialmente con respecto al manejo de errores. Await hace que se vea muy limpio.

Si uso esperar aquí, ¿cuál es el punto del método asíncrono?

await no bloquea el hilo. MyMethod2 se ejecutará sincrónicamente hasta que alcance la expresión de await . Entonces MyMethod2 se suspenderá hasta que se complete la tarea esperada ( MyMethod ). Mientras MyMethod no se completa, el control volverá a la persona que llama de MyMethod2 . Ese es el punto de await : la persona que llama continuará haciendo su trabajo .

¿No hace que el asíncrono sea inútil que VS me diga que llame en espera?

async es solo una bandera que significa 'en algún lugar del método tiene uno o más en espera'.

¿Eso no anula el propósito de descargar una tarea a un hilo sin esperar a que termine?

Como se describió anteriormente, no tiene que esperar a que finalice la tarea. Aquí no hay nada bloqueado.

NOTA: Para seguir los estándares de nomenclatura del marco, le sugiero que agregue el sufijo Async a los nombres de métodos asíncronos.

Un método asíncrono no se ejecuta automáticamente en un subproceso diferente. En realidad, lo contrario es cierto: un método async siempre se ejecuta en el subproceso de llamada. async significa que este es un método que puede dar lugar a una operación asíncrona. Eso significa que puede devolver el control a la persona que llama mientras espera que se complete la otra ejecución. Entonces, los métodos asnync son una forma de esperar otras operaciones asíncronas.

Dado que no está haciendo nada para esperar en MyMethod2 , async no tiene sentido aquí, por lo que su compilador le advierte.

Curiosamente, el equipo que implementó los métodos async reconoció que marcar un método async no es realmente necesario, ya que bastaría con usar await en el cuerpo del método para que el compilador lo reconozca como asíncrono. Se agregó el requisito de usar la palabra clave async para evitar romper los cambios en el código existente que usa await como nombre de variable.