Why does this C# program execute the statements after await?

Question

The following program executes both WriteLines, even though the task is never awaited:

var nonAwaitedTask = Foo();
Thread.Sleep(10);

static async Task Foo()
{
    Console.WriteLine("before delay");
    await Task.Delay(1);
    Console.WriteLine("after delay");
}

When removing Thread.Sleep the second WriteLine is not executed.

Is this a race condition even though only the main thread should be involved? When and why does the (main) thread continue execution of the async code (MoveNext)?

---

I could see multiple scenarios where the WriteLine could be executed, e.g.:

• if await Task.Delay(0) was used (awaiter.IsCompleted is immediately true and Foo would not yield).
• if await Task.Delay(1).ConfigureAwait(false) was used (a different thread could run the code while the main thread is blocking on Thread.Sleep)
• if we await (e.g. a Task.Delay(10)) in Main (instead of blocking on Thread.Sleep) which would allow Foo to run concurrently.

I understand that the latter two would be race-conditions and that the first compiler optimisation might not be guaranteed (in short, just await your tasks). However, my mental model where only one thread is involved and where this thread could only continue execution on well defined (await) points does not seem to hold.

Any explanations are highly appreciated!

Answer 1

If this is all your program then you can call it kind of race condition between the process being closed and Foo being completed. You can rewrite the app to:

var nonAwaitedTask = Foo();
Console.ReadKey();

// ...

With the same effect as Thread.Sleep(10);.

Task.Delay(1); is so called "truly async" operation and since it seems you are running a console app with no synchronization context involved (hence ConfigureAwait will have no effect) so the continuation (Console.WriteLine("after delay");) will be scheduled on any thread pool thread. await-ing does not affect the task completion it affects the calling method being able to wait/observe it.

var nonAwaitedTask = Foo(); is basically a fire-and-forget task.

Read more:

• Asynchronous programming
• There Is No Thread - I would argue that this one can be crucial here
• Asynchronous Programming in .NET - Introduction, Misconceptions, and Problems
• ConfigureAwait FAQ

Answer 2

I'm guessing you are running in a console program. This is somewhat different compared to a UI program

1. If you use a regular void main you risk the program exiting before all tasks have completed. You can use 'async main', i.e. static async Task Main(string[] args) to avoid this.
2. There is no UI context that ensure everything run on a single thread. Instead anything after an await will run on some arbitrary threadpool thread.

Is this a race condition even though only the main thread should be involved?

Yes, if you use await in a console program there will be multiple threads involved, unless you do something to override the scheduler.

I would recommend using the term 'ui thread', since that is less ambiguous than 'main thread'. In a console program the main thread is not that different from an arbitrary thread pool thread.

When and why does the (main) thread continue execution of the async code (MoveNext)?

The compiler will rewrite Foo so that it returns the task at the first await. At that point the caller is free to continue with other stuff unless it awaits the returned task.

In the end I would recommend using an async main method, and ensure that all tasks are awaited. That should help a bit at avoiding some of the threading issues.