Async Await and the Generated StateMachine

Introduction

Like everybody around, I went digging into .NET 4.5 to see what's new... but
I didn't find any good step by step explanations about how the state
machine actually works, so I used ilspy, and along with a good video from the creator,
I got a good notion of what is what. (and you are welcome to have a peek too).

The State Machine

I read somewhere that you can think of it like this:

Call "before" code

Call await code as task

Store "after" code in a continuation task

But this isn’t really the case.

What really happens is actually something like this:

On compile time:

A structcalled
StateMachine is generated

Contains fields to save function local state

A moveNext function is created which holds the entire code

The code is fragmented by await calls into several cases (machine states)

Share

About the Author

I've been all over the coding world since earning my degreeshave worked in c++ and java, finally setteling into c# about 6 years ago, where i spent a good amount of my time in Performance tweaking & memory debugging, as well as designing new solutions and hacking at old ones to stay in line.

Computers never cease to amaze me, and i'm glad to have found a field where i get paid to do what i enjoy.

I have been toying around with the idea of publishing stuff online for years, never actually getting around to it, so i still have a lot of stuff to write up, aside from all the other new stuff i'll get excited about, hope you'll like enjoy reading it as much as i enjoy writing.

This whole mechanism is geared towards client code (the synchronization context bit is a dead giveaway)Also, when coding on the server side, you usually want the threads you are running in to be created and managed by the server and not by your own mechanisms, this is since threads created by TPL calls will not have direct access to HttpContext/current WCF object, making security & correct user logging a challange.Even if you choose to use async await on server side, and you don't mind the non-server thread issues, the small overhead should be weighed against the time saving benefits of running in parallel (...and the programmer time saving benefits of clear, managable code ).

Wow, I'm shocked at how little you know vs how much you're willling to talk!

You basically seem to know nothing about server programming. Having access to HttpContext is a non-issue, and the whole point of using Async/Await is to NOT use server threads, so your first response is a bit strange.

Async/Await is actually TPL, and we use it on the server all the time. You might want ot review how to use a enterprise service bus, or message passing to see how client communication is typically handled.

Having said that, my question was a simple one that applies to both client and server, the overhead won't change, just the speed of the processor(s) in some cases.

BTW, synchronization context wasn't the giveway, I sort of got that you were talking client side when you said GUI thread.

The HttpContext problem is something that was an issue for me when working with WebServices on iis, and later when migrating to WCF.. so, even though you might not have an issue with it on your project it doesn't say nobody has a problem with it.

When coding pure infrastructure logic (like message passing), there is no problem, but when trying to do parallel work with BusinessLogic flows, you run into some difficulty, especially if you have some legacy code to work with.You do have AspNetSynchronizationContext, but when using it, you don't really get a parallel behavior, since it makes sure tasks will run one at a time, each one capturing the context in turn, as you can see in Stephen Cleary's article:"If multiple operations complete at once for the same application, AspNetSynchronizationContext will ensure that they execute one at a time."

While async await uses TPL it is not "actually TPL", it is a new api with it's own default behaviors - for example the different exception handling (first exception is thrown out), and the fact that the use of CurrentSyncContext is implicit, instead of explicit like TPL.

I am still convinced that the default behavior of this api is geared towards GUI applications (specifically the new Win8 metro GUI), but that doesn't mean that you can't use it to code server-side flows, just that you should know your stuff before you actually do it.

When wakeup call is issued by OS:
Thread which handles the await continuation is called

If i understood correctly: Main Thread creates and runs a new async task (in another thread, for instance Thread2) and moves on. Later when Thread2 terminates, a wake-up event is fired in the Main Thread and the framework executes the code that corresponds to the continuation block.

So, the Main Thread must have a message loop, to catch the "wake-up" event, right?

What happens in Console applications, that do not have a message loop?

Or is it some other other construct of the .NET framework that handles this event?

This is taken from MSDN:If a synchronization context (SynchronizationContext object) is associated with the thread that was executing the asynchronous method at the time of suspension (for example, if the SynchronizationContext.Current property is not null), the asynchronous method resumes on that same synchronization context by using the context’s Post method. Otherwise, it relies on the task scheduler (TaskScheduler object) that was current at the time of suspension. Typically, this is the default task scheduler (TaskScheduler.Default), which targets the thread pool. This task scheduler determines whether the awaited asynchronous operation should resume where it completed or whether the resumption should be scheduled. The default scheduler typically allows the continuation to run on the thread that the awaited operation completed.

What actually happens is:* The code runs synchronously on the main thread until await* Await is called, and scheduled in another thread (or uses IO completion if relevant)* When it's time to run the "after" block, 1. If the SynchronizationContext exists for the orignial calling thread, it is used (which brings us to GUI thread) 2. If no sync context is available the default scheduler is used, which takes a thread from pool. (this will happen when no pump exist, like in console apps)see here: Bnaya Eshet's "the concept of async" blog

So if I understand correctly, for GUI apps it is 100% that the after block will execute in the UI thread (provided the method awaited at the UI thread too), so there is no need to check "InvokeRequired", and

for console apps the "after" block will possibly execute on a different thread.

Since the main idea is keeping the code flow as simple as a syncronous function, removing all those invokes and checks from the code is part of the solution.

If you are in a GUI application, but writing a non gui operation and you don't want it to jump back into the GUI thread via the syncContext, you can use task.ConfigureAwait(false) on the task returned from the async function, making the threads to be taken from the pool. (thus getting console app behavior inside a GUI app)

I looked it up and you are absolutely right!I had a notion that passing a ValueType created on stack, by ref will get it boxed, turnes out that is wrong, what is passed is a reference to the location on stack..Nevertheless, this doesn't change the general behavior - since boxing occures two calls into the mechanism when state machine struct is set to a member field of type IAsyncStateMachine, which causes it to box onto the heap. (this is done on purpose, since call will now return and the stack - unwind).