Practical example of async await does not meet expectations

Question

Related to this question: Does await completely blocks the thread?

[...] it will first check to see if the called method completed, and if not will register the continuation and return from that method call. Later, once that method completes, it will re-enter the state-machine in order to complete the method

And to this question also: When is the best place to use Task.Result instead of awaiting Task

await simply means "this workflow cannot progress further until this task is completed, so if it is not complete, find more work to do and come back later"

And finally to this post: https://blog.stephencleary.com/2012/02/async-and-await.html

If “await” sees that the awaitable has not completed, then it acts asynchronously. It tells the awaitable to run the remainder of the method when it completes, and then returns from the async method. Later on, when the awaitable completes, it will execute the remainder of the async method. If you’re awaiting a built-in awaitable (such as a task), then the remainder of the async method will execute on a “context” that was captured before the “await” returned.

So from these posts I get that the await operator does indeed not block, but when I've tried to test it i just cannot get this principle to work the way it states to work. Obviously I'm missing something:

    //This will take 10 seconds
    [HttpGet("test1")]
    public async Task<TimeSpan> test()
    {
        var t1 = DateTime.Now;

        var wait1 = DoAsyncEcho("The first!", 10000);
        var wait2 = DoAsyncEcho("The second!", 10000);


        _logger.LogInformation(await wait1);
        _logger.LogInformation(await wait2);
        _logger.LogInformation("DONE!");

        var t2 = DateTime.Now;
        return t2 - t1;
    }

    //This will take 10 seconds too
    [HttpGet("test2")]
    public async Task<TimeSpan> test2()
    {
        var t1 = DateTime.Now;

        var wait1 = DoAsyncEcho("The first!", 10000);
        var wait2 = DoAsyncEcho("The second!", 10000);

        Thread.Sleep(10000);

        _logger.LogInformation(await wait1);
        _logger.LogInformation(await wait2);
        _logger.LogInformation("DONE!");

        var t2 = DateTime.Now;
        return t2 - t1;
    }


    //This will take 20
    [HttpGet("test3")]
    public async Task<TimeSpan> test3()
    {
        var t1 = DateTime.Now;

        var wait1 = await DoAsyncEcho("The first!", 10000);
        var wait2 = await DoAsyncEcho("The second!", 10000);

        _logger.LogInformation(wait1);
        _logger.LogInformation(wait2);
        _logger.LogInformation("DONE!");

        var t2 = DateTime.Now;
        return t2 - t1;
    }



    //This will take 30
    [HttpGet("test4")]
    public async Task<TimeSpan> test4()
    {
        var t1 = DateTime.Now;

        var wait1 = await DoAsyncEcho("The first!", 10000);
        var wait2 = await DoAsyncEcho("The second!", 10000);

        Thread.Sleep(10000);

        _logger.LogInformation(wait1);
        _logger.LogInformation(wait2);
        _logger.LogInformation("DONE!");

        var t2 = DateTime.Now;
        return t2 - t1;
    }

    private Task<string> DoAsyncEcho(string v, int t)
    {
        return Task<string>.Factory.StartNew(() =>
            {
                Thread.Sleep(t);
                return v;
            }
        );
    }

As I see from the methods test3 and test4, await does indeed wait, it does not enter into a state-machine and does a callback later on because it waits the full 10 seconds of the first DoAsyncEcho and then another 10s on the second call. On the methods test1 and test2 execution time lasts for 10s as code does not waits for the return of the DoAsyncEcho but only it awaits for the result later. Particulary test2 method sleeps the 3 calls of 10 seconds in parallel so after all it's just a 10s run.

What do I'm missing here?

Answer 1

I think the best way to demonstrate this is through a simple Windows Forms app.

Create a default Windows Forms app and drop 3 buttons onto it (called button1, button2 and button3.

Then add the following code:

async void button1_Click(object sender, EventArgs e)
{
    this.Text = "[button1_Click] About to await slowMethodAsync()";
    int result = await slowMethodAsync();
    this.Text = "[button1_Click] slowMethodAsync() returned " + result;
}

void button2_Click(object sender, EventArgs e)
{
    this.Text = "[button2_Click] About to start task to call slowMethod()";
    int result = 0;

    Task.Run(() =>
    {
        result = slowMethod();
    }).ContinueWith(_ =>
    {
        this.Invoke(new Action(() =>
        {
            this.Text = "[button2_Click] slowMethod() returned " + result;
        }));
    });
}

void button3_Click(object sender, EventArgs e)
{
    this.Text = "[button3_Click] About to call slowMethod()";
    int result = slowMethod();
    this.Text = "[button3_Click] slowMethod() returned " + result;
}

static async Task<int> slowMethodAsync()
{
    await Task.Delay(5000);
    return 42;
}

static int slowMethod()
{
    Thread.Sleep(5000);
    return 42;
}

If you try this code out, you will notice the following:

Pressing button1 will immediately change the title to [button1_Click] About to await Task.Delay(5000), and you can resize the dialog while waiting for 5 seconds, after which the title will change to [button1_Click] Awaited Task.Delay(5000).

The code for handling button2 is very roughly equivalent to the state machine that is generated from the await code for button1. If you press button2, you will see similar effects to pressing button1.

(The actual code for await is in reality quite different, but the underlying mechanism of using a continuation - i.e., ContinueWith() and Invoke(), to continue executing the code after the await on the UI thread illustrates its approach.)

The code for button3 completely blocks during the Thread.Sleep(), and if you press button3 the UI locks up completely for 5 seconds,.

---

To illustrate what happens with a non-UI example, consider the following console application:

using System;
using System.Threading;
using System.Threading.Tasks;

namespace Demo
{
    static class Program
    {
        static async Task Main()
        {
            Console.WriteLine("Main thread ID = " + Thread.CurrentThread.ManagedThreadId);

            int result = slowMethod();

            Console.WriteLine("result = " + result);
            Console.WriteLine("After calling slowMethod(), thread ID = " + Thread.CurrentThread.ManagedThreadId);

            result = await slowMethodAsync();
            Console.WriteLine("result = " + result);
            Console.WriteLine("After calling slowMethodAsync(), thread ID = " + Thread.CurrentThread.ManagedThreadId);
        }

        static async Task<int> slowMethodAsync()
        {
            await Task.Delay(5000);
            return 42;
        }

        static int slowMethod()
        {
            Thread.Sleep(5000);
            return 42;
        }
    }
}

If you run that, you will see output similar to the following:

Main thread ID = 1
result = 42
After calling slowMethod(), thread ID = 1
result = 42
After calling slowMethodAsync(), thread ID = 4

Note how the code has resumed on a different thread after the await.

The key thing to realise is that as far as calling code is concerned, y = await X(); does not return until it has a value to return, and the code that runs afterwards may be running on a different thread.

The effect of this in terms of blocking THREADS is that the calling thread is freed up to go off and execute some other code, and another thread is only required when the async method returns.

In many cases, this means that no additional thread is required (for the continuation), and in all cases it means that the original calling thread is not blocked and can be freed up to the thread pool for use for another task.

This is the "non blocking" part of all this.

For a good, detailed explanation of why sometimes no additional thread is needed, read Stephen Cleary's excellent "There is no thread".

Answer 2

It seems that you are confusing two different interpretations of wait and block. The objective of asynchronous code is to block your code, while the thread remains unblocked. If you don't want to block your code, then the solution is easy: don't use await. But if you don't block your code, then you can't use the result of the asynchronous operation, because the asynchronous operation is running concurrently with your code.

What has not happened yet belongs to the future, and the future is unknown. Not only do you not know the result, you don't even know if the operation succeeded or failed. In most cases this is problematic. You need the result of the operation before continuing with processing this result. So you must block your code. And this is why await was invented, to block your code without having to block a thread too.

You need the thread to remain unblocked, so that it continues running the UI message pump that keeps your application responsive. Just because your code is blocked, your _application) need not to be blocked also. For ASP.NET applications, you need the thread to remain unblocked so that it can serve other incoming web requests. The fewer threads you block, the more requests you can serve. In this case async/await becomes a booster of scalability.