C# 5异步函数特性的一大好处是,它为异步提供了一致的方案。但如果在命名异步方法以及 触发异常等方面做法存在着差异,则很容易破坏这种一致性。微软因此发布了基于任务的异步模 式(Task-based Asynchronous Pattern,TAP),即提出了每个人都应遵守的约定。TAP有单独的文 件(http://mng.bz/B68W),MSDN中也有它的页面(http://mng.bz/4N39)。
基于IO的操作会将工作移交给硬盘或其他计算机,这非常适合异步,而且没有明显的缺点。 CPU密集型的任务就不那么适合了。可以很轻松地将一些工作移交给线程池,在.NET 4.5中也要 比以前更加简单,这都要感谢 Task.Run 方法,但使用代码库来实现这一点,相当于为调用者做 了决定。不同的调用者可能会有不同的需求。如果仅仅暴露同步风格的方法,相当于为调用者提 供了灵活性,以保证其以最适合的方式进行工作。它们可以在需要时开始一个新任务,如果可以 接受当前线程在一段时间内忙于执行方法,也可以实现同步调用。
1 public static async Task<int> ProcessRecords() 2 { 3 List<Record> records = await FetchRecordsAsync().ConfigureAwait(false); 4 //记录处理 5 await SaveResultsAsync(results).ConfigureAwait(false); 6 //让调用者知道处理了多少条记录 7 return records.Count; 8 }
该方法大部分代码在线程池线程上执行。由于并没有要求在原始线程中执行,因此这正是我 们想要的结果。(专业术语叫做该操作没有线程亲和力(thread affinity)。)但这并不会影响调用 者,如果异步UI方法等待的是调用 ProcessRecords 的结果,则该异步方法将继续在UI线程上执 行。只有在 ProcessRecords 内部的代码声明其不关心执行上下文时,才会在线程池线程上执行。
有争议的是,没有必要在第二个 await 表达式处调用 ConfigureAwait ,因为所剩工作已经 不多了,但通常来说我们应该在每个 await 表达式处调用该方法,而保持一致是个好习惯。如果 想为调用者提供方法执行上下文的灵活性,可将其作为异步方法参数。
注意, ConfigureAwait 只会影响执行上下文的同步部分。而有关模拟(impersonation)等 其他部分,传播则并不关心,15.6.4节将详细介绍相关内容。