Can exiting an async method yield control back to a different async method?

Question

I understand that async which awaits a task yields execution back to the caller, allowing it to continue until it needs the result.

My interpretation of what I thought would come out of this was correct up until a certain point. It looks as though there's some sort of interleaving going on. I expected Do3() to complete and then back up the call stack to Do2(). See the results.

        await this.Go();

Which calls

        async Task Go()
        {
            await Do1(async () => await Do2("Foo"));

            Debug.WriteLine("Completed async work");
        }

        async Task Do1(Func<Task> doFunc)
        {
            Debug.WriteLine("Start Do1");

            var t = Do2("Bar");

            await doFunc();

            await t;
        }

        async Task Do2(string id)
        {
            Debug.WriteLine("Start Do2: " + id);

            await Task.Yield();

            await Do3(id);

            Debug.WriteLine("End Do2: " + id);
        }

        async Task Do3(string id)
        {
            Debug.WriteLine("Start Do3: " + id);

            await Task.Yield();

            Debug.WriteLine("End Do3: " + id); // I did not expect Do2 to execute here once the method call for Do3() ended
        }

The expected outcome:

// Start Do1
// Start Do2: Bar
// Start Do2: Foo
// Start Do3: Bar
// Start Do3: Foo
// End Do3: Bar
// End Do2: Bar
// End Do3: Foo
// End Do2: Foo
//Completed async work

Actual output:

//Start Do1
//Start Do2: Bar
//Start Do2: Foo
//Start Do3: Bar
//Start Do3: Foo
//End Do3: Bar
//End Do3: Foo
//End Do2: Bar
//End Do2: Foo
//Completed async work

What's going on here exactly?

I'm using .NET 4.5 and a simple WPF app to test my code.

Man, can you simplify this? Hard work to trace through all those calls. — usr, May 21 '14 at 14:14
In WinForms (vs WPF), the expected and the actual output do match. — noseratio, May 22 '14 at 03:30

score 2 · Accepted Answer · edited May 23 '17 at 11:50

This is a WPF app, and all of this code is executed on the same UI thread. Each await continuation in your code is scheduled via DispatcherSynchronizationContext.Post, which posts a special Windows message to the UI thread's message queue. Each continuation happens in the order its message was posted (this is implementation-specific and you should not rely upon this, but that's how it works here).

So, the continuation for End Do3: Foo is indeed posted right after the one for End Do3: Bar. The output is correct.

Now, a bit more details. When I asked about WinForms vs WPF, I expected your "expected" output to match the actual output. I just tested it under WinForms, and it does match:

// Start Do1
// Start Do2: Bar
// Start Do2: Foo
// Start Do3: Bar
// Start Do3: Foo
// End Do3: Bar
// End Do2: Bar
// End Do3: Foo
// End Do2: Foo
//Completed async work

So, why the discrepancy between WPF and WinForms, while both run a message loop, and we only deal with single-threaded code here? The answer can be found here:

Why a unique synchronization context for each Dispatcher.BeginInvoke callback?

WPF's DispatcherSynchronizationContext.Post just calls Dispatcher.BeginInvoke, and one substantial WPF's implementation detail is that each Dispatcher.BeginInvoke callback is executed on its own unique synchronization context, as explained in the linked question.

This affects the await continuations for Task objects (like await doFunc()). In WinForms, such continuations are inlined (executed synchronously), because SynchronizationContext.Current stays the same. In WPF, they're not inlined but rather posted via SynchronizationContext.Post, because SynchronizationContext.Current before await task and after completion of the task is not the same (it gets compared inside task.GetAwaiter().OnCompleted by the await runtime infrastructure code).

Thus, in WPF, it's often the same UI thread, but different synchronization context associated with this thread, so the continuation may incur one more asynchronous PostMessage callback to be posted to, pumped and executed by the message loop. Besides YieldAwaitable (returned by Task.Yield), you'd also experience this behavior for TaskCompletionSource.SetResult-style continuations triggered from a WPF UI thread.

This is rather complex but implementation-specific stuff. If you want to have precise control over the order of asynchronous await continuations, you may want to roll out your own synchronization context, similar to Stephen Toub's AsyncPump. Although usually you don't need that, especially for a UI thread.

Are you saying the same UI thread is time sharing the execution based on the method body which is in scope (the implementation detail)? — Razor, May 22 '14 at 01:59
@VincePanuccio, basically yes. If `Go` has been started on the UI thread, then the code chunks between awaits are executed on the same UI thread in the serial order here. This is what the message loop does. The only asynchrony in your code is `DispatcherSynchronizationContext.Post`. — noseratio, May 22 '14 at 02:18

score 0 · Answer 2 · answered May 21 '14 at 14:10

The outcome doesn't surprise me. If Do3 is ended, I don't see why it should make Do2 continue immediately. It's all part of the asynchronous process, so the actual output makes perfect sense. It wouldn't surprise me, though, if a different run would give a different outcome.

Do3:Bar and Do3:Foo are different tasks, (probably) executed simultaneously in different threads. After they finish, their respective callers are notified, but that notification in itself is probably also asynchronous. await doesn't make two task magically run in the same thread, it just makes the first one wait until the other one is done. So while Do2:Bar is waiting for that signal, Do3:Foo can just continue to run and finish.

Exactly my point. Do3 Bar has not finished executing along its path and I would expect it to fall back to Do2 Bar, but as soon as Do3 Bar completes, execution is handed back to Foo. I have also added Thread.CurrenctThread.ManagedThreadID to my Debug statements and the thread ID is the same all the way through. — Razor, May 22 '14 at 01:56

Can exiting an async method yield control back to a different async method?

2 Answers2