How async task doesn't block UI

Question

I have this code:

private async void Button_Click(object sender, RoutedEventArgs e)
{
    Task<int> i = LongTaskAsync();    // first break point here
    int k = await i;
    print("Done, i=" + i);
}
private async Task<int> LongTaskAsync()
{
    await System.Threading.Tasks.Task.Delay(5 * 1000); // second break point here
    return 10;
}

When debugging, I knew that LongTaskAsync was running on UI thread. So, why it doesn't block UI and how?

Answer 1

Information from MSDN

The method runs synchronously until it reaches its first await expression, at which point the method is suspended until the awaited task is complete.In the meantime, control returns to the caller of the method

Answer 2

Function button_click is declared async. This function calls an async function. Calling an async function does not run the code immediately as calling a normal function would do. Instead the code is scheduled as a request to run a Task by one of the threads in a collection of available threads that is known as the thread pool.

After scheduling the task, the caller of the async function continues with the next statements until it reaches the statement to await for the result of the scheduled task. Quite often, the await is immediately after the call to the async function, but it does not have to.

Task<int> longRunningTask = LongTaskAsync();
// because of not awaiting, your thread is free to do other things:
DoSomethingElse();

// now I need the result: await for the longRunningTask
int i = await longRunningTask;
ProcessResult(i);

Whenever one of the threads in the thread pool is free, it will check if a piece of code is scheduled and if so it will run the code. If this thread calls another async function, the task is scheduled etc.

Most async functions will somewhere await for the results of the tasks they scheduled. In fact, your compiler will warn you if you forget to await the task. To enable your callers to await for your async function to complete, your function returns Task or Task<TResult> instead of void or TResult.

The only exception is the event handler: this method can return void. This has the effect that the task will be scheduled, but that the caller cannot await for it.

This caller is your application. The application schedules a task to handle the button clicked event but does not await until this event is finished. Hence your application will remain responsive.

Because button_click is async, your UI thread does not wait for this function to finish. Hence your program could enter this function again before LongTaskAsync is finished. Quite often this is an undesired effect and you should take care that this does not happen, for instance by disabling the button at the entrance of the event function and enable it when the event is finished. Something like this:

private async void Button_Click(object sender, RoutedEventArgs e)
{
    // Prevent entering again before this function is finished:
    Button clickedButton = (Button)sender;
    clickedButton.Enabled = false;

    // process the clicked button:
    Task<int> i = LongTaskAsync();    // first break point here
    int k = await i;
    print("Done, i=" + i);

    // Finished processing, enable the button again:
    clickedButton.Enabled = true;
}

Answer 3

Because async/await construction is running asynchronously - so it doesn't block UI. In your method "int k = await i;" runs asynchronously. "Use the async modifier to specify that a method, lambda expression, or anonymous method is asynchronous. The method runs synchronously until it reaches its first await expression, at which point the method is suspended until the awaited task is complete. In the meantime, control returns to the caller of the method". That's why your UI is not blocked.

Answer 4

I had the same question when I tried writing Android code. Background task is different from the foreground UI task and they run independently.

AsyncTasks usually uses up threads in the foreground to update UI and do UI related tasks

For example,

AsyncTask(params)-> {
@Override
   protected void onPreExecute() {
      super.onPreExecute();
     ..........
   }

   @Override
   protected String doInBackground(String... params) {
   ...............
   }

   @Override
   protected void onProgressUpdate(Integer... values) {
   ...............
   }

   @Override
   protected void onPostExecute(String result) {
   .................
   }
}

Here, each of the tasks could be handled in its own UI thread without interfering with the background job and when the background job is finished, you could update the UI. In the mean time, you could use some UI animation to keep the UI busy.

Answer 5

Your sample is not enough to test the asynchronous behavoiur, I tested the behavior with a console application.

static void Main(string[] args)
{
     string value1 = "First";
     Console.WriteLine(value1);

     GetSecondFromAsync();

     string value3 = "Third";
     Console.WriteLine(value3);

     string value4 = "Fourth";
     Console.WriteLine(value4);

     Console.ReadKey();
}

private static async void GetSecondFromAsync()
{
   await Task.Delay(3000);
   Console.WriteLine("Second");
}

Information from MSDN,

The method runs synchronously until it reaches its first await expression, at which point the method is suspended until the awaited task is complete.In the meantime, control returns to the caller of the method

At the point of first await in GetSecondFromAsync(), only this method is suspended and the control returns to the caller and executes the remaining. So the output will be like

First
Third
Fourth
Second

That means the thread comes in the Main is not blocked, it goes on..