async/await problem - what happens what the operation awaited ends?

Question

I think I've read around 20 async/await articles, multiple questions on SO and I still have lots of gaps in understanding how it works, especially when multiple threads are involved and when its all done using one thread.

I wrote myself this piece of code to test one scenario:

static async Task Main(string[] args)
        {
            var longTask = DoSomethingLong();

            for (int i = 0; i < 1000; i++)
                Console.Write(".");

            await longTask;
        }

        static async Task DoSomethingLong()
        {
            await Task.Delay(10);
            for (int i = 0; i < 1000; i++)
                Console.Write("<");
        }

I'm explicitly letting my Main continue with writing the dots to the console while the execution is blocked on delay inside DoSomethingLong. I see that after delay ends, the dots writing and < sign writing start interfering with each other.

I just can't figure out: is it two threads that are doing this work simultaneously? One writes the dots and the other writes the other characters? Or is it somehow one thread but switching between those contexts? I would say it's the first option but still I am not sure. When can I expect an additional thread to be created when using async/await? This is still not clear to me.

Also is it always the same thread that will execute Mai, reach the await and then come back to write the dots?

Answer 1

var longTask = DoSomethingLong();

This line creates a Task. This is a different task compared to a task created by Task.Run(). This is a task based on a state machine, auto-generated by the C# compiler. Here is what the compiler generates (copy-pasted from sharplab.io):

using System;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Security;
using System.Security.Permissions;
using System.Threading.Tasks;

[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default
    | DebuggableAttribute.DebuggingModes.DisableOptimizations
    | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints
    | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]
[assembly: AssemblyVersion("0.0.0.0")]
[module: UnverifiableCode]
public class Program
{
    [CompilerGenerated]
    private sealed class <DoSomethingLong>d__0 : IAsyncStateMachine
    {
        public int <>1__state;

        public AsyncTaskMethodBuilder <>t__builder;

        private int <i>5__1;

        private TaskAwaiter <>u__1;

        private void MoveNext()
        {
            int num = <>1__state;
            try
            {
                TaskAwaiter awaiter;
                if (num != 0)
                {
                    awaiter = Task.Delay(10).GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        num = (<>1__state = 0);
                        <>u__1 = awaiter;
                        <DoSomethingLong>d__0 stateMachine = this;
                        <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);
                        return;
                    }
                }
                else
                {
                    awaiter = <>u__1;
                    <>u__1 = default(TaskAwaiter);
                    num = (<>1__state = -1);
                }
                awaiter.GetResult();
                <i>5__1 = 0;
                while (<i>5__1 < 1000)
                {
                    Console.Write("<");
                    <i>5__1++;
                }
            }
            catch (Exception exception)
            {
                <>1__state = -2;
                <>t__builder.SetException(exception);
                return;
            }
            <>1__state = -2;
            <>t__builder.SetResult();
        }

        void IAsyncStateMachine.MoveNext()
        {
            // ILSpy generated this explicit interface implementation from
            // .override directive in MoveNext
            this.MoveNext();
        }

        [DebuggerHidden]
        private void SetStateMachine(IAsyncStateMachine stateMachine)
        {
        }

        void IAsyncStateMachine.SetStateMachine(IAsyncStateMachine stateMachine)
        {
            // ILSpy generated this explicit interface implementation from
            // .override directive in SetStateMachine
            this.SetStateMachine(stateMachine);
        }
    }

    [AsyncStateMachine(typeof(<DoSomethingLong>d__0))]
    [DebuggerStepThrough]
    private static Task DoSomethingLong()
    {
        <DoSomethingLong>d__0 stateMachine = new <DoSomethingLong>d__0();
        stateMachine.<>t__builder = AsyncTaskMethodBuilder.Create();
        stateMachine.<>1__state = -1;
        AsyncTaskMethodBuilder <>t__builder = stateMachine.<>t__builder;
        <>t__builder.Start(ref stateMachine);
        return stateMachine.<>t__builder.Task;
    }
}

What happens in practice is that the first part of the DoSomethingLong method is executed synchronously. It is the part before the first await. In this specific case there is nothing before the first await, so the call to DoSomethingLong returns almost immediately. It only has to register a continuation with the rest of the code, to run in a thread-pool thread after 10 msec. After the return of the call, this code runs in the main thread:

for (int i = 0; i < 1000; i++)
    Console.Write(".");

await longTask;

While this code is running, the thread-pool is signalled to run the scheduled continuation. It starts running in parallel in a thread-pool thread.

for (int i = 0; i < 1000; i++)
    Console.Write("<");

It is a good thing that the Console is thread-safe, because it is called by two threads concurrently. If it wasn't, your program could crash!

Answer 2

Since they happen at the same time they are on different threads. It all depends on the context handling the tasks. You can set it to allow only one task to run at one time, or many. By default it handles multiple.

In this case the DoSomething() starts running when you call it. When printing out thread IDs it shows that after the delay another is started to print out the <. By having the await in the method it creates another thread to run it and falls back to run Main because there is no await telling it to wait on it before continuing.

As for will the code continue to run on the same thread that depends on context given and if ConfigureAwait is used. For example, ASP.NET doesn’t have a context so the execution will continue in whatever thread happens to be available. In WPF by default it will run on the same thread as it started, unless ConfigureAwait(false) is used to tell the system it may run in whatever thread available.

In this console example after awaiting the DoSomething() the Main will continue on its thread, not on the one that started the whole program on my test case. This is logical since console program doesn’t have a context either to manage which thread runs which part.

Here's a modified code to test what's happening on the specific implementation:

static async Task Main(string[] args)
{
    Console.WriteLine("Start: " + Thread.CurrentThread.ManagedThreadId);
    var longTask = DoSomethingLong();
    Console.WriteLine("After long: " + Thread.CurrentThread.ManagedThreadId);

    for (int i = 0; i < 1000; i++)
        Console.Write(".");

    Console.WriteLine("Before main wait: " + Thread.CurrentThread.ManagedThreadId);
    await longTask;
    Console.WriteLine("After main wait: " + Thread.CurrentThread.ManagedThreadId);
}

static async Task DoSomethingLong()
{
    Console.WriteLine("Before long wait: " + Thread.CurrentThread.ManagedThreadId);
    await Task.Delay(10);
    Console.WriteLine("After long wait: " + Thread.CurrentThread.ManagedThreadId);
    for (int i = 0; i < 1000; i++)
        Console.Write("<");
}

On mine (.NET Core 3.0 preview 7) it will display this:

Start: 1
After long: 1
Before long wait: 1
After long wait: 4
Before main wait: 1
After main wait: 4

The last one may be 1 or 4 on my system depending on which thread happens to be available. This shows how awaiting for Task.Delay() will drop out of the DoSomethingLong() method, resume running Main, and after the delay it needs another thread to continue running DoSomethingLong() since the original thread is busy doing other things.

Interestingly (at least to me), even when running DoSomethingLong() directly with await the ManagedThreadIds do the same thing. I would've expected there to be only thread ID 1 in that case, but that's not what the implementation does it seems.