没有 I/O 的 await 开销是多少

Question

C# 5 中异步模式的一个缺点是任务不是协变的，即没有 ITask<out TResult>

我注意到我的开发人员经常这样做

return await SomeAsyncMethod(); 

解决这个问题。

这个板条箱究竟会对性能产生什么影响？没有 I/O 或线程产量，它只会等待并将其转换为正确的协变，在这种情况下，异步框架将在幕后做什么？会有线程上下文切换吗？

编辑：更多信息，此代码无法编译

public class ListProductsQueryHandler : IQueryHandler<ListProductsQuery, IEnumerable<Product>>
{
    private readonly IBusinessContext _context;

    public ListProductsQueryHandler(IBusinessContext context)
    {
        _context = context;
    }

    public Task<IEnumerable<Product>> Handle(ListProductsQuery query)
    {
        return _context.DbSet<Product>().ToListAsync();
    }
}

因为 Task 不是协变的，而是添加了 await ，它会将其强制转换为正确的 IEnumerable 而不是 ToListAsync 返回的 List

ConfigureAwait(false) 域代码中的任何地方都不是一个可行的解决方案，但我肯定会将它用于我的低级方法，例如

public async Task<object> Invoke(Query query)
{
    var dtoType = query.GetType();
    var resultType = GetResultType(dtoType.BaseType);
    var handler = _container.GetInstance(typeof(IQueryHandler<,>).MakeGenericType(dtoType, resultType)) as dynamic;
    return await handler.Handle(query as dynamic).ConfigureAwait(false);
}

Answer 1

您解决此问题的方法更显着的成本是，如果SynchronizationContext.Current 中有一个值，您需要向它发布一个值并等待它安排该工作。如果上下文正忙于做其他工作，您可能会等待一段时间，而您实际上不需要在该上下文中执行任何操作。

这可以通过简单地使用ConfigureAwait(false) 来避免，同时仍然保留async 方法。

一旦您消除了使用同步上下文的可能性，那么async 方法生成的状态机的开销不应明显高于您在显式添加延续时需要提供的开销。

Answer 2

有一些相关的开销，虽然大多数时候，不会有上下文切换 - 大部分成本是在为每个带有等待的异步方法生成的状态机中。主要问题是是否存在阻止继续同步运行的东西。由于我们讨论的是 I/O 操作，因此开销与实际的 I/O 操作相比往往相形见绌——同样，主要的例外是 Winforms 使用的同步上下文。

为了减少这种开销，你可以让自己成为一个辅助方法：

public static Task<TOut> Cast<TIn, TOut>(this Task<TIn> @this, TOut defaultValue)
  where TIn : TOut
{
    return @this.ContinueWith(t => (TOut)t.GetAwaiter().GetResult());
}

（defaultValue 参数仅用于类型推断 - 遗憾的是，您必须明确写出返回类型，但至少您不必手动输入“输入”类型）

示例用法：

public class A
{
    public string Data;
}

public class B : A { }

public async Task<B> GetAsync()
{
    return new B { Data = 
     (await new HttpClient().GetAsync("http://www.google.com")).ReasonPhrase };
}

public Task<A> WrapAsync()
{
    return GetAsync().Cast(default(A));
}

如果需要，您可以尝试一些调整，例如使用TaskContinuationOptions.ExecuteSynchronously，它应该适用于大多数任务调度程序。

Answer 3

这个板条箱究竟会对性能产生什么影响？

几乎没有。

会有线程上下文切换吗？

不比平常多。

正如我在博客中所描述的，when an await decides to yield, it will first capture the current context (SynchronizationContext.Current, unless it is null, in which case the context is TaskScheduler.Current). Then, when the task completes, the async method resumes executing in that context.

此对话中的另一个重要元素是task continuations execute synchronously if possible（同样，在我的博客中进行了描述）。请注意，这实际上并没有记录在任何地方；这是一个实现细节。

ConfigureAwait(false) 域代码中的任何地方都不是一个可行的解决方案

您可以在您的域代码中使用ConfigureAwait(false)（出于语义原因，我实际上建议您这样做），但在这种情况下它可能不会对性能产生任何影响。这就是为什么...

让我们考虑一下这个调用在您的应用程序中是如何工作的。毫无疑问，您有一些依赖于上下文的入门级代码 - 例如，按钮单击处理程序或 ASP.NET MVC 操作。这会调用有问题的代码 - 执行“异步转换”的域代码。这反过来又调用了已经在使用ConfigureAwait(false)的低级代码。

如果您在域代码中使用ConfigureAwait(false)，完成逻辑将如下所示：

1. 低级任务完成。由于这可能是基于 I/O 的，因此任务完成代码在线程池线程上运行。
2. 低级任务完成代码继续执行域级代码。由于未捕获上下文，域级代码（强制转换）在同一线程池线程上执行，同步。
3. 域级代码到达其方法的末尾，从而完成域级任务。此任务完成代码仍在同一个线程池线程上运行。
4. 域级任务完成代码继续执行入门级代码。由于入门级需要上下文，因此入门级代码排队到该上下文。在 UI 应用中，这会导致线程切换到 UI 线程。

如果您不在您的域代码中使用ConfigureAwait(false)，完成逻辑将如下所示：

1. 低级任务完成。由于这可能是基于 I/O 的，因此任务完成代码在线程池线程上运行。
2. 低级任务完成代码继续执行域级代码。由于上下文被捕获，域级代码（演员表）排队到该上下文。在 UI 应用中，这会导致线程切换到 UI 线程。
3. 域级代码到达其方法的末尾，从而完成域级任务。此任务完成代码正在上下文中运行。
4. 域级任务完成代码继续执行入门级代码。入门级需要已经存在的上下文。

所以，这只是上下文切换发生时间的问题。对于 UI 应用程序，尽可能长时间地在线程池上保留少量工作是很好的，但对于大多数应用程序来说，如果不这样做也不会影响性能。同样，对于 ASP.NET 应用程序，如果您将尽可能多的代码保留在请求上下文之外，则可以免费获得少量并行性，但对于大多数应用程序而言，这无关紧要。

Answer 4

编译器会生成一个状态机，在调用方法时保存当前的SynchornizationContext，在await之后恢复。

因此可能存在上下文切换，例如当您从 UI 线程调用它时，await 之后的代码将切换回在 UI 线程上运行，这将导致上下文切换。

这篇文章可能有用Asynchronous Programming - Async Performance: Understanding the Costs of Async and Await

在您的情况下，在 await 之后粘贴 ConfigureAwait(false) 可能会很方便，以避免上下文切换，但是仍然会生成 async 方法的状态机。最后，await 的成本与您的查询成本相比可以忽略不计。