How do yield and await implement flow of control in .NET?

by

I’ll answer your specific questions below, but you would likely do well to simply read my extensive articles on how we designed yield and await.

https://blogs.msdn.microsoft.com/ericlippert/tag/continuation-passing-style/

https://blogs.msdn.microsoft.com/ericlippert/tag/iterators/

https://blogs.msdn.microsoft.com/ericlippert/tag/async/

Some of these articles are out of date now; the code generated is different in a lot of ways. But these will certainly give you the idea of how it works.

Also, if you do not understand how lambdas are generated as closure classes, understand that first. You won’t make heads or tails of async if you don’t have lambdas down.

When an await is reached, how does the runtime know what piece of code should execute next?

await is generated as:

if (the task is not completed)
  assign a delegate which executes the remainder of the method as the continuation of the task
  return to the caller
else
  execute the remainder of the method now

That’s basically it. Await is just a fancy return.

How does it know when it can resume where it left off, and how does it remember where?

Well, how do you do that without await? When method foo calls method bar, somehow we remember how to get back to the middle of foo, with all the locals of the activation of foo intact, no matter what bar does.

You know how that’s done in assembler. An activation record for foo is pushed onto the stack; it contains the values of the locals. At the point of the call the return address in foo is pushed onto the stack. When bar is done, the stack pointer and instruction pointer are reset to where they need to be and foo keeps going from where it left off.

The continuation of an await is exactly the same, except that the record is put onto the heap for the obvious reason that the sequence of activations does not form a stack.

The delegate which await gives as the continuation to the task contains (1) a number which is the input to a lookup table that gives the instruction pointer that you need to execute next, and (2) all the values of locals and temporaries.

There is some additional gear in there; for instance, in .NET it is illegal to branch into the middle of a try block, so you can’t simply stick the address of code inside a try block into the table. But these are bookkeeping details. Conceptually, the activation record is simply moved onto the heap.

What happens to the current call stack, does it get saved somehow?

The relevant information in the current activation record is never put on the stack in the first place; it is allocated off the heap from the get-go. (Well, formal parameters are passed on the stack or in registers normally and then copied into a heap location when the method begins.)

The activation records of the callers are not stored; the await is probably going to return to them, remember, so they’ll be dealt with normally.

Note that this is a germane difference between the simplified continuation passing style of await, and true call-with-current-continuation structures that you see in languages like Scheme. In those languages the entire continuation including the continuation back into the callers is captured by call-cc.

What if the calling method makes other method calls before it awaits– why doesn’t the stack get overwritten?

Those method calls return, and so their activation records are no longer on the stack at the point of the await.

And how on earth would the runtime work its way through all this in the case of an exception and a stack unwind?

In the event of an uncaught exception, the exception is caught, stored inside the task, and re-thrown when the task’s result is fetched.

Remember all that bookkeeping I mentioned before? Getting exception semantics right was a huge pain, let me tell you.

When yield is reached, how does the runtime keep track of the point where things should be picked up? How is iterator state preserved?

Same way. The state of locals is moved onto the heap, and a number representing the instruction at which MoveNext should resume the next time it is called is stored along with the locals.

And again, there’s a bunch of gear in an iterator block to make sure that exceptions are handled correctly.

More Related Contents:

  1. How and when to use ‘async’ and ‘await’
  2. If async-await doesn’t create any additional threads, then how does it make applications responsive?
  3. HttpClient.GetAsync(…) never returns when using await/async
  4. Should I avoid ‘async void’ event handlers?
  5. Running multiple async tasks and waiting for them all to complete
  6. Fire and forget async method in asp.net mvc
  7. Task sequencing and re-entracy
  8. Enforce an async method to be called once
  9. Why use Async/await all the way down
  10. Async and await – difference between console, Windows Forms and ASP.NET
  11. Different forms of the WCF service contract interface
  12. How does async works in C#?
  13. Why use async and return await, when you can return Task directly?
  14. Executing tasks in parallel
  15. Should I worry about “This async method lacks ‘await’ operators and will run synchronously” warning
  16. Proper way to start and fire-and-forget asynchronous calls?
  17. Use Task.Run() in synchronous method to avoid deadlock waiting on async method?
  18. A pattern for self-cancelling and restarting task
  19. Async always WaitingForActivation
  20. What is the correct way to cancel an async operation that doesn’t accept a CancellationToken?
  21. A pattern to pause/resume an async task?
  22. Async thread body loop, It just works, but how?
  23. Converting async/await to Task.ContinueWith
  24. Horrible performance using SqlCommand Async methods with large data
  25. How to Async Files.ReadAllLines and await for results?
  26. Async and Await with For Loop [duplicate]
  27. Await and SynchronizationContext in a managed component hosted by an unmanaged app
  28. When is the best place to use Task.Result instead of awaiting Task
  29. Timeout pattern on task-based asynchronous method in C#
  30. ASP.NET Controller: An asynchronous module or handler completed while an asynchronous operation was still pending

Leave a Comment