Cuando el método devuelve vacío, ¿es lo mismo que una tarea?

Question

Estoy intentando el async CTP, la versión 4.5 que permite utilizar métodos asíncronos sin necesidad de escribir los métodos Begin/End.

Mi primera prueba es ejecutar un método asíncrono que devuelve vacío. Puedo ver algunos ejemplos y hacer lo siguiente:

private void btnAsync01_Click(object sender, RoutedEventArgs e) 
{ 
    UpdateTxtLog("click button: " + System.DateTime.Now); 
    method01Async(); 
    UpdateTxtLog("after ethod01Async: " + System.DateTime.Now); 
} 

private async void method01Async() 
{ 
    await TaskEx.Run(() => 
    { 
     UpdateTxtLog("Enter method01Async: " + System.DateTime.Now); 
     Thread.Sleep(10000); 
     UpdateTxtLog("exit method01Async: " + System.DateTime.Now); 
    }); 
} 

En mi proyecto WPF tengo un cuadro de texto donde ver los resultados y un botón que ejecuta el método asíncrono.

En el método asíncrono, uso await, es necesario porque el método es asíncrono, y TasEx.Run para crear un nuevo hilo en el que ejecutar el código.

Mi duda es en este punto. En algunos ejemplos que veo de cómo crear un método asíncrono que devuelve vacío, use de esta manera, Task.Run o TaskEx.Run.

Si no me equivoco, Task.Run crea un nuevo hilo donde ejecutar el método. Entonces, ¿por qué usar un método asíncrono, si con la Tarea, crear un nuevo hilo, obtengo lo que quiero, no para bloquear el hilo principal?

Además, si el método asíncrono accede a alguna variable compartida, debo tener cuidado con la concurrencia, ¿verdad? Por lo tanto, no conozco la ventaja de utilizar métodos asíncronos, al menos en este caso.

De hecho, utilizo el mismo código sin async y sin esperar y el resultado es el mismo, el programa principal no está bloqueando y todo funciona como esperaba. El método es el siguiente:

private void method01Async() 
{ 
    TaskEx.Run(() => 
    { 
     UpdateTxtLog("Enter method01Async: " + System.DateTime.Now); 
     Thread.Sleep(10000); 
     UpdateTxtLog("Exit method01Async: " + System.DateTime.Now); 
    }); 
} 

Mi pregunta es, esta es la forma correcta de utilizar asíncrono cuando el retorno void método?

Answer 1

Si no estoy equivocado, Task.Run crear un nuevo hilo donde para ejecutar el método.

No exactamente. Task.Run() ejecutará el código en un subproceso diferente del subproceso de interfaz de usuario (al menos con el predeterminado TaskScheduler). Pero en realidad no creará un nuevo hilo en la mayoría de los casos, reutilizará un hilo existente del ThreadPool.

Entonces, ¿por qué utilizar un método asíncrono, si con la Tarea, crear un nuevo hilo, obtengo lo que quiero, no para bloquear el hilo principal?

El punto de async, en el contexto de una aplicación de interfaz de usuario, es ser capaz de ejecutar fácilmente un cierto código en el hilo de interfaz de usuario después de y operación asincrónica.

lo tanto, si usted hizo su method01Async “awaitable”, es decir, hecho que devolver un Task:

private async Task method01Async() 
{ 
    await Task.Run(/* whatever */); 
} 

A continuación, podría esperar que a partir del método btnAsync01_Click, si lo hizo `asíncrono:

private async void btnAsync01_Click(object sender, RoutedEventArgs e) 
{ 
    UpdateTxtLog("click button: " + System.DateTime.Now); 
    await method01Async(); 
    UpdateTxtLog("after method01Async: " + System.DateTime.Now); 
} 

De esta forma, la última línea del método se ejecutará solo después de que se ejecute Task en method01Async. Y se ejecutará en el hilo de UI.

En .Net 4.0, se puede lograr un efecto similar usando ContinueWith() y Dispatcher.Invoke():

private void btnAsync01_Click(object sender, RoutedEventArgs e) 
{ 
    UpdateTxtLog("click button: " + System.DateTime.Now); 
    method01Async().ContinueWith(() => 
     Dispatcher.Invoke(
      new Action(() => 
       UpdateTxtLog("after method01Async: " + System.DateTime.Now))); 
} 

Estoy seguro de que estará de acuerdo en que esto es mucho más sucio y menos legible.

Además, si el método asíncrono accede a alguna variable compartida, debo tener cuidado con la concurrencia, ¿verdad?

Sí, tienes razón al respecto.

De hecho, utilizo el mismo código sin async y sin esperar y el resultado es el mismo, el programa principal no está bloqueando y todo funciona como esperaba.

El resultado ciertamente no es lo que pensé que debía hacer su código. La última línea de btnAsync01_Click, ejecutará "after method01Async", pero no esperará hasta que el Task iniciado en ese método finalice.

---

Como nota al margen, no hay necesidad de utilizar async en su method01Async. Volviendo al Task directamente (o no, si desea mantenerlo void -Volviendo), funcionará de la misma:

private Task method01Async() 
{ 
    return Task.Run(/* whatever */); 
} 

Answer 2

En realidad, no está utilizando la función asíncrona, ya que no está esperando la llamada original. Aquí es cómo usted debe hacer es:

private async void btnAsync01_Click(object sender, RoutedEventArgs e) 
{ 
    UpdateTxtLog("click button: " + System.DateTime.Now); 
    await method01Async(); 
    UpdateTxtLog("after ethod01Async: " + System.DateTime.Now); 
} 

private async Task method01Async() 
{ 
    return await TaskEx.Run(() => 
    { 
     UpdateTxtLog("Enter method01Async: " + System.DateTime.Now); 
     Thread.Sleep(10000); 
     UpdateTxtLog("exit method01Async: " + System.DateTime.Now); 
    }); 
} 

Una vez que se cambie a esta (la parte importante de los cuales await method01Async() en su botón de evento de clic, saltará volver allí después de que salga, y el "después ethod01Async:" de registro de texto debe mostrar un segundo retraso de diez, al igual que su registro de "salida method01Async" en el método method01Async.