目录
开始用async/await
最近几个项目中涉及到了.Net Framework 4.5和WinRT，这才算用上了之前一直认为是新·语法糖的async/await异步编程方式。类似之前需要等待一段时间才能完成的的代码——比如网络访问、文件读写、新dialog中用户交互等——可以不用启动新的线程、等待回调、返回到UI线程后再更新界面，而是直接按照同步方式进行调用。代码的可读性会大大提高，这一点毋庸置疑，例如下面的（伪）代码：
void Download( string fileUri ) {
Networking.Download( fileUri, ( response ) => {
Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => {
DownloadStatus = "Done!";
} );
} );
}
就可以转写为：
async void Download( string fileUri ) {
await Networking.Download( fileUri );
DownloadStatus = "Done!";
}
至少最后那堆括号没有了。实际上async/await提供的不仅是语义上更符合常理的用法。那么这是如何实现的？
[Symbian中的实现]
说点题外话。有过Symbian开发经验的程序员一定也遇到过异步方法需要同步调用的头疼情况，例如用户选取Gallery中的图片或者需要等待网络请求完成后再继续操作。由于Active Object的存在，Symbian中的单线程模拟异步方式实现起来麻烦得很，所以后来大家要么用局部TReqeustStatus+FOREVER循环，要么用User::WaitForRequest()的方式卡死当前上下文。结果就是导致了无数奇怪的Bug。这部分和本文其实没什么太大关系，只是因为当年被Symbian荼毒过深，不由自主想起来了而已:)。
新模型的基本概念
先从结论说起：async/await理论上讲还是C#语言层次的语法糖，在IL层面不涉及到新的指令；但它的实现并非“启动一个新线程去更新数据”，而是利用同步上下文实现了并行性（Concurrency），比起多线程来说，这个实现无论在时间还是空间消耗上，性能并不逊色[2]。
退一步说，不要说新的线程，async关键字本身甚至不会导致函数以异步方式运行，不管这个函数是否有Task或者Task<>返回值，它所做的就是标记内部可能会有await实现[3]。而在另一方面，await用于标记可等待（awaitable）的实现方法。简单说来就是在await出现的地方，把后面需要同步执行的代码作为“后续（continuation）”记录，当作异步方法的回调；这样异步方法调用部分将会和同步方法“分离（slicing）”开来，包装成数段代码，后面几节会很清晰地看到——后续的同步代码会作为delegate在异步操作完成后执行。
从IL入手
了解语法层面新关键字、功能的实现，ildasm永远是最好用的。大概在大前年还是前年，项目不太紧张的时候我跟着《Microsoft .Net IL汇编语言程序设计》和另外一本《IL Book》看了一段时间IL指令集，记了些笔记，还手写过点代码片段。可惜后来扔下了，因为越看越觉得过于细节接触IL指令集没什么大用，随用随查才是王道。基础指令还是应该记下来，以备不时之需，必须现在就需要了。这里我就不列出具体的指令作用，如果有需要的同学可以参考Under the covers of the async modifier and await operator in .NET 4.5 and C# Metro style applications这篇精彩的分析[4]，里面用表格形式说明了具体类似于stloc, stfld, ldarg, ldloc, new等等指令和IL code中各field的作用。
那么先写出C#代码：
class AsyncClass {
public async void FooAsync() {
int i = 10;
var files = await ApplicationData.Current.LocalFolder.GetFilesAsync();
i = 20;
}
public async Task FooAsync2() {
int i = 10;
var files = await ApplicationData.Current.LocalFolder.GetFilesAsync();
i = 20;
return string.Empty;
}
}
用ildasm打开，大概的情况如图：
首先值得值得注意的是，就如同匿名方法、扩展方法一样，async/await并未引入任何新的IL指令，一切都是通过上层实现的。可以看到IL Assemler生成了两个形如< FooAsync >d__0的结构体，继续打开看看：
这个结构体从IAsyncStateMachine实现，包含很多field和两个方法MoveNext和SetStateMachine。这些field中包括执行上下文的this指针（AsyncClass）、async方法内用到的局部变量（files, i, j），再加上框架生成的状态机相关的类（awaiter等）。SetStateMachine明显是IAsyncStateMachine接口中定义的需要实现的方法，那么MoveNext打开看看（IL代码太多，故都折叠了）：
.method private hidebysig newslot virtual final
instance void MoveNext() cil managed
{
.override [System.Threading.Tasks]System.Runtime.CompilerServices.IAsyncStateMachine::MoveNext
// 代码大小 213 (0xd5)
.maxstack 3
.locals init ([0] bool '<>t__doFinallyBodies',
[1] class [System.Runtime]System.Exception '<>t__ex',
[2] int32 CS$4$0000,
[3] valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1> CS$0$0001,
[4] valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1> CS$0$0002,
[5] class [System.Runtime]System.Collections.Generic.IReadOnlyList`1 CS$0$0003)
.try
{
IL_0000: ldc.i4.1
IL_0001: stloc.0
IL_0002: ldarg.0
IL_0003: ldfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_0008: stloc.2
IL_0009: ldloc.2
IL_000a: ldc.i4.s -3
IL_000c: beq.s IL_0014
IL_000e: ldloc.2
IL_000f: ldc.i4.0
IL_0010: beq.s IL_0019
IL_0012: br.s IL_001b
IL_0014: br IL_00a4
IL_0019: br.s IL_0065
IL_001b: br.s IL_001d
IL_001d: nop
IL_001e: ldarg.0
IL_001f: ldc.i4.s 10
IL_0021: stfld int32 BehindAsync.AsyncClass/'d__0'::'5__1'
IL_0026: call class [Windows]Windows.Storage.ApplicationData [Windows]Windows.Storage.ApplicationData::get_Current()
IL_002b: callvirt instance class [Windows]Windows.Storage.StorageFolder [Windows]Windows.Storage.ApplicationData::get_LocalFolder()
IL_0030: callvirt instance class [Windows]Windows.Foundation.IAsyncOperation`1> [Windows]Windows.Storage.StorageFolder::GetFilesAsync()
IL_0035: call valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1 [System.Runtime.WindowsRuntime]System.WindowsRuntimeSystemExtensions::GetAwaiter>(class [Windows]Windows.Foundation.IAsyncOperation`1)
IL_003a: stloc.3
IL_003b: ldloca.s CS$0$0001
IL_003d: call instance bool valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1>::get_IsCompleted()
IL_0042: brtrue.s IL_0083
IL_0044: ldarg.0
IL_0045: ldc.i4.0
IL_0046: stfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_004b: ldarg.0
IL_004c: ldloc.3
IL_004d: stfld valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1> BehindAsync.AsyncClass/'d__0'::'<>u__$awaiter3'
IL_0052: ldarg.0
IL_0053: ldflda valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder BehindAsync.AsyncClass/'d__0'::'<>t__builder'
IL_0058: ldloca.s CS$0$0001
IL_005a: ldarg.0
IL_005b: call instance void [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder::AwaitUnsafeOnCompleted>,valuetype BehindAsync.AsyncClass/'d__0'>(!!0&,
!!1&)
IL_0060: nop
IL_0061: ldc.i4.0
IL_0062: stloc.0
IL_0063: leave.s IL_00d3
IL_0065: ldarg.0
IL_0066: ldfld valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1> BehindAsync.AsyncClass/'d__0'::'<>u__$awaiter3'
IL_006b: stloc.3
IL_006c: ldarg.0
IL_006d: ldloca.s CS$0$0002
IL_006f: initobj valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1>
IL_0075: ldloc.s CS$0$0002
IL_0077: stfld valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1> BehindAsync.AsyncClass/'d__0'::'<>u__$awaiter3'
IL_007c: ldarg.0
IL_007d: ldc.i4.m1
IL_007e: stfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_0083: ldloca.s CS$0$0001
IL_0085: call instance !0 valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1>::GetResult()
IL_008a: ldloca.s CS$0$0001
IL_008c: initobj valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.TaskAwaiter`1>
IL_0092: stloc.s CS$0$0003
IL_0094: ldarg.0
IL_0095: ldloc.s CS$0$0003
IL_0097: stfld class [System.Runtime]System.Collections.Generic.IReadOnlyList`1 BehindAsync.AsyncClass/'d__0'::'5__2'
IL_009c: ldarg.0
IL_009d: ldc.i4.s 20
IL_009f: stfld int32 BehindAsync.AsyncClass/'d__0'::'5__1'
IL_00a4: leave.s IL_00be
} // end .try
catch [System.Runtime]System.Exception
{
IL_00a6: stloc.1
IL_00a7: ldarg.0
IL_00a8: ldc.i4.s -2
IL_00aa: stfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_00af: ldarg.0
IL_00b0: ldflda valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder BehindAsync.AsyncClass/'d__0'::'<>t__builder'
IL_00b5: ldloc.1
IL_00b6: call instance void [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder::SetException(class [System.Runtime]System.Exception)
IL_00bb: nop
IL_00bc: leave.s IL_00d3
} // end handler
IL_00be: nop
IL_00bf: ldarg.0
IL_00c0: ldc.i4.s -2
IL_00c2: stfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_00c7: ldarg.0
IL_00c8: ldflda valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder BehindAsync.AsyncClass/'d__0'::'<>t__builder'
IL_00cd: call instance void [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder::SetResult()
IL_00d2: nop
IL_00d3: nop
IL_00d4: ret
} // end of method 'd__0'::MoveNext
虽然一眼看到了实际的异步方法调用确实被包装在了MoveNext中，但这里面的处理略显复杂。跟着IL代码从头走下来是最简单直接的途径，无他。那么具体这个方法做了什么事？
首先可以看到IL_0003到0C段，状态机通过switch语句进行了状态__state检查：
- 是否同-3相等，如果是跳转到IL_0014处。这个跳转又直接br到了IL_00a4，直接退出了程序，那么这里应该是__state==COMPLETED一类的处理。
- 是否同0相等，如果是跳转到IL_0019处，接着跳转到IL_0065，用于处理最后一段同步代码。这里__state被赋值为-1，awaiter被初始化，等待调用。接下来awaiter.GetResult()调用，__state赋值-2，刚刚得到的Result被用于AsyncVoidMethodBuilder::SetResult()，这里应该是没有后续await方法的情况。函数返回，等待下一步调用（退出）。
- 是否既不为-3又不为0，如果是则跳转到IL_001b，接着跳转到IL_001d，用于处理第一段同步代码。这里实际的异步方法被调用。awaiter::get_IsCompleted()被检查是否为true，也就是说如果awaitable Task被完成了的话，直接跳转到刚刚awaiter.GetResult()的地方；如果未完成，则__state赋值为0，调用AsyncVoidMethodBuilder::AwaitUnsafeOnCompleted，传入awaiter和this作为参数，函数就此返回，等待下一步调用。
除了正常流程之外，对于执行期间的异常也进行了捕获。出现后__state赋值为-2，并且调用AsyncVoidMethodBuilder::SetException进行处理。
框架为了驱动整个流程，似乎初始时候的__state不能为0，这个猜测也在后面得到了印证。对于所生成结构体运转的结构和理解就是这样了，那么回到原先的AsyncClass处，打开第一个方法FooAsync()：
.method public hidebysig instance void FooAsync() cil managed
{
.custom instance void [System.Diagnostics.Debug]System.Diagnostics.DebuggerStepThroughAttribute::.ctor() = ( 01 00 00 00 )
.custom instance void [System.Runtime]System.Runtime.CompilerServices.AsyncStateMachineAttribute::.ctor(class [System.Runtime]System.Type) = ( 01 00 25 42 65 68 69 6E 64 41 73 79 6E 63 2E 41 // ..%BehindAsync.A
73 79 6E 63 43 6C 61 73 73 2B 3C 46 6F 6F 41 73 // syncClass+d__0..
// 代码大小 48 (0x30)
.maxstack 2
.locals init (valuetype BehindAsync.AsyncClass/'d__0' V_0,
valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder V_1)
IL_0000: ldloca.s V_0
IL_0002: ldarg.0
IL_0003: stfld class BehindAsync.AsyncClass BehindAsync.AsyncClass/'d__0'::'<>4__this'
IL_0008: ldloca.s V_0
IL_000a: call valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder::Create()
IL_000f: stfld valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder BehindAsync.AsyncClass/'d__0'::'<>t__builder'
IL_0014: ldloca.s V_0
IL_0016: ldc.i4.m1
IL_0017: stfld int32 BehindAsync.AsyncClass/'d__0'::'<>1__state'
IL_001c: ldloca.s V_0
IL_001e: ldfld valuetype [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder BehindAsync.AsyncClass/'d__0'::'<>t__builder'
IL_0023: stloc.1
IL_0024: ldloca.s V_1
IL_0026: ldloca.s V_0
IL_0028: call instance void [System.Threading.Tasks]System.Runtime.CompilerServices.AsyncVoidMethodBuilder::Startd__0'>(!!0&)
IL_002d: br.s IL_002f
IL_002f: ret
} // end of method AsyncClass::FooAsync
在此方法中，我们对于await XXXAsync()的调用被翻译成了AsyncVoidMethodBuilder的创建（000a)、初始化(000f-0023）和启动（0028）过程。可以注意到在IL_0016处，刚刚看到的__state被初始化为-1。生成的d__0被传入，用于驱动状态机。
用过IL代码了解流程可以保证准确性，但其可读性连差强人意都算不上。后面利用大牛们写的一些C#层次的分析文章，我会回顾一下上面提到的流程，以便更加清楚整个状态机是如何运转起来的。
回到C#代码
IL Spy的作者Daniel Grunwald在2.0版本中试着对async/await相关机制进行了反编译的支持，其中提到编译器生成的代码（compiler generation）类似于yield语句的代码结构，就如我们在上面IL代码中看到的一样，整个awaitable task运转过程是由状态机驱动的。只不过那篇Blog撰写时候IL Spy的async/await解析支持还在制作中，所以生成的C#代码并非完美。
下面则是一个更接近于实际代码的版本[7]，整体的数据结构和代码流程和上面一节的分析没有太大区别。
[CompilerGenerated]
[StructLayout(LayoutKind.Auto)]
internal struct MethodAsyncStateMachine : IAsyncStateMachine
{
public int State;
public AsyncTaskMethodBuilder Builder;
public int Arg0;
public int Arg1;
public int Result;
private TaskAwaiter awaitor;
void IAsyncStateMachine.MoveNext()
{
try
{
if (this.State != 0)
{
this.awaitor = HelperMethods.MethodTask(this.Arg0, this.Arg1).GetAwaiter();
if (!this.awaitor.IsCompleted)
{
this.State = 0;
this.Builder.AwaitUnsafeOnCompleted(ref this.awaitor, ref this);
return;
}
}
else
{
this.State = -1;
}
this.Result = this.awaitor.GetResult();
}
catch (Exception exception)
{
this.State = -2;
this.Builder.SetException(exception);
return;
}
this.State = -2;
this.Builder.SetResult(this.Result);
}
[DebuggerHidden]
void IAsyncStateMachine.SetStateMachine(IAsyncStateMachine param0)
{
this.Builder.SetStateMachine(param0);
}
}
那么回想提一下，开始时候我们提到过同一个方法内的方法分片（slicing），也就是说不连续的await调用会被视为多段代码，同步调用亦是如此。那么在具体实现上，这些代码段是作为多个状态存在吗？试验一下即可，把FooAsync改为下面这样：
public async void FooAsync() {
int i = 10;
var files = await ApplicationData.Current.LocalFolder.GetFilesAsync();
i = 20;
var folders = await ApplicationData.Current.LocalFolder.GetFoldersAsync();
i = 30;
var items = await ApplicationData.Current.LocalFolder.GetItemsAsync();
int j = 0;
}
用ildasm打开后可以看到，整体的代码并没有出现奇怪的变化，只是随着代码量变大指令调用也多了（不贴了，因为太多，关键在于那个switch table），可视的变化包括：多了两个awaiter；__state的判断多了“1”和“2”两种情况。似乎可以推断出，在StateMachine Struct::MoveNext()，是将原有代码按照一段同步异步代码+一段同步代码组合起来作为一个State，并且State的序号从0开始。以每一段await调用为分界点，将代码切分，异步代码部分作为awaiter存在，后续的同步代码则用匿名函数包装作为回调，在awaiter返回后调用。结合之前的分析结果，__state对应到具体的状态上大概是：
- state == -3：直接结束（似乎只用于比较结果）
- state == -2：流程完毕
- state == -1：流程开始
- state >= 0：第state + 1段异步同步+同步代码
但从实际的生成代码来看，在MoveNext()中调用时视觉上和我们的分析刚好反过来，在switch语句中是一段同步代码跟着一段异步的，在case语句块中的逻辑类似于：执行同步代码、执行异步代码、检查是否Complete、更新__state（置为后续state或者-2）。实际的生成代码中，则是将struct本身指针的MoveNext()方法调用置于awaiter的完成回调中，利用递归实现了状态机的变化[7]，更容易阅读和接近实际情况的代码也可以在[7]中看到。
await, awaiter, awaitable
什么是awaitable？顾名思义就是可以用await进行调用的对象。从上面几节的分析可以得出，XXXAsync函数之所以可用await关键字修饰，在于它返回了Task对象（或是Task对象。那么除了Task对象之外，还有其他的awaitable对象。例如Task::ConfigureTask()会得到一个ConfiguredTaskAwaitable对象，这个对象可以await。除此之外Task::Yield()会返回YieldAwaitable[8]。
我们可以自己构建awaitable对象吗？当然可以，只不过.Net并未提供相关接口，都需要自己进行实现。我们在用var folders = await ApplicationData.Current.LocalFolder.GetFoldersAsync();调用方法的时候，实际上等同于
var operation = ApplicationData.Current.LocalFolder.GetFoldersAsync();
var task = operation.AsTask>();
var awaiter = task.GetAwaiter();
var folders = awaiter.GetResult();
这样一来，我们就知道awaitable对象必须返回一个awaiter，而awaiter需要信号量标识是否完成以及提供返回结果的接口——实现ICriticalNotifyCompletion：
- bool IsCompleted { get; }
- void OnCompleted(Action continuation); （这里的continuation就是刚刚提到MoveNext中异步代码后续的同步代码）
- TResult GetResult();
注意到没，这些Property和Function刚才都在生成代码中见过了。这是一个泛型版本，非泛型的版本仅仅是GetResult()不返回值。在[8]中已经有了实现INotifyCompletion的泛型/非泛型版本的完备版本，同时也有利用现有Task、TaskAwaiter对Action和Func直接进行扩展方法书写，让其支持await调用的例子，大家可以移步参考。
最后一点……Task
Task::ConfigureTask()拿到的ConfiguredTaskAwaitable到底有什么用？ConfigureTask方法接受一个bool值，如果为false则系统可能不会准确地返回到当前的上下文继续执行callback的同步代码，而是在系统认为合适的地方执行[5]。换句话说，如果你在UI线程利用AsTask().ConfirgureTask(false)进行了异步操作，那么要小心这行代码后面的同步代码是否修改了UI控件或是绑定的数据，因为它不一定会回到UI线程继续执行。
Task还提供了一对方法WhenAny()和WhenAll()以及它们的泛型版本，用来对多个同时进行的任务进行同步。从函数名字可以一目了然地清楚它们的作用：传入多个awaitable object后，可以实现类似使用Mutex或是ResetEvent的线程同步。
参考资料
[1] Asynchronous Programming with Async and Await (C# and Visual Basic), MSDN
[2] What is the cost of async/await?, Bnaya Eshet
[3] Async/Await FAQ, MSDN
[4] Under the covers of the async modifier and await operator in .NET 4.5 and C# Metro style applications, Pete Brown
[5] Diving deep with WinRT and await, Windows 8 app developer blog
[6] Decompiling Async/Await, Daniel Grunwald
[7] Understanding C# async / await (1) Compilation, Dixin
[8] Understanding C# async / await (2) Awaitable / Awaiter Pattern, Dixin
