是否有任何使用新的 async/await 功能编写 .NET API 的指南

Question

我目前正在设计一些内部 API，其中使用 Async CTP 及其新的 await/async 关键字。

是否有关于如何设计这些 API 的指南或最佳实践？

具体来说：

• 我应该提供同步和异步版本的方法吗？ （即 Task DoStuffAsync() 和 void DoStuff()
• 我公开的所有异步方法是否应该采用 async Task形式？ GetStuffAsync() （即方法名称以 Async 结尾）或者可以让名为 GetStuff() 的东西等待吗

？这里并非全黑或白，这取决于所讨论的方法，但我正在寻找一般准则。

Answer 1

很难找到有价值的内容，大多数出版物都集中在客户端编程方面。好东西是：

• 标题为“基于任务的异步模式”的白皮书。下载 在这里（注意：archive.org 备份，下载按钮截至 2024 年 5 月仍然有效）。
• Stephen Toub 在 Windows Build 上做了一次演讲，讨论了优化模式和许多重要的提示。有一个视频< /a>，也可用打印。

请记住，这都是预览版，重要细节可能会在发布之前发生变化。

Answer 2

使用await实现异步API时要使用的一件重要事情是确保使用ConfigureAwait(false) 每当您想要在 API 实现中等待任务时。它的作用是允许 TPL 使用 TPL 默认行为（线程池）而不是 TaskAwaiter 的默认行为（当前同步上下文）来安排等待恢复。

对于使用者来说，使用当前同步上下文是正确的默认行为，因为如果您已经在 UI 线程上，它允许诸如等待返回 UI 线程之类的操作。但是，如果 UI 线程无法执行该方法的其余部分，则尝试返回 UI 线程可能会出现问题。 await 获取线程执行该方法的方式是在底层创建委托的标准 .NET 约定。然后，这些委托将被发送到以任何类型的调度机制（例如 WinForms 消息泵、WPF 调度程序或任何其他机制）进行处理。

然而，对于 API 实现来说，尝试返回相同的上下文通常是错误的，因为这隐式地依赖于可用于执行的原始上下文。

例如，如果我在 UI 线程上有一些代码：

void MyUIThreadCode() {
    Task asyncTask = MyAsyncMethod();
    asyncTask.Wait();
}

async Task MyAsyncMethod() {
    await DownloadSomethingAsync();
    ComputeSomethingElse();
}

这种代码[b]非常[/b]很容易写，而且很容易导致挂起。典型的情况是，在MyAsyncMethod()内部，有一个使用默认同步上下文调度的await。这意味着在 UI 上下文中，将调用 DownloadSomethingAsync() 方法，然后开始下载。

MyAsyncMethod() 然后测试 await 操作数是否“完成”。假设下载尚未完成，那么 await 的定义行为就是去掉该方法的“其余部分”，并安排在 await 完成后执行该方法> 操作数确实已完成。

因此...执行方法其余部分的状态被隐藏在委托中，现在 MyAsyncMethod() 将其自己的任务返回给 MyUIThreadCode()。

现在，MyUIThreadCode() 对返回的任务调用 Task.Wait()。但问题是 .NET 中的 Task 实际上是具有“完成”概念的任何事物的通用表示。仅仅因为您有一个 Task 对象，就无法保证它将如何执行，也无法保证它将如何完成。如果您猜测的话，另一件事不能保证是它的隐式依赖关系。

因此，在上面的示例中，MyAsyncMethod() 在任务上使用默认的等待行为，该行为在当前上下文上安排方法延续。方法延续需要在 MyAsyncMethod() 返回的任务被视为完成之前执行。

但是，MyUIThreadCode() 在任务上调用了Wait()。定义的行为是阻止当前线程，将当前函数保留在堆栈上，并有效地等待任务完成。

用户在这里没有意识到的是，他们被阻止的任务依赖于主动处理的 UI 线程，但它无法执行此操作，因为它仍在忙于执行在 Wait() 调用上被阻止的函数。

1. 为了让 MyUIThreadCode() 完成其方法调用，它需要 Wait() 返回 (2)
2. 为了让 Wait() 返回，它需要 asyncTask 来完成 (3)。
3. 为了完成 asyncTask，需要执行 MyAsyncMethod() 的方法延续 (4)。
4. 为了让方法继续运行，它需要处理消息循环 (5)。
5. 为了让消息循环继续处理，它需要 MyUIThreadCode() 返回 (1)。

明确了循环依赖关系，最终没有一个条件得到满足，并且 UI 线程实际上挂起。

以下是使用ConfigureAwait(false) 修复此问题的方法：

void MyUIThreadCode() {
    Task asyncTask = MyAsyncMethod();
    asyncTask.Wait();
}

async Task MyAsyncMethod() {
    await DownloadSomethingAsync().ConfigureAwait(false);
    ComputeSomethingElse();
}

这里发生的情况是，MyAsyncMethod() 的方法延续使用TPL 默认值（线程池），而不是当前的同步上下文。现在，该行为的条件如下：

1. 为了让 MyUIThreadCode() 完成其方法调用，它需要 Wait() 返回 (2)
2. 为了让 Wait() 返回，它需要 asyncTask 来完成 (3)。
3. 为了完成 asyncTask，需要执行 MyAsyncMethod() 的方法延续 (4)。
4. （新） 为了让方法延续运行，它需要线程池进行处理 (5)。
5. 实际上，线程池始终在处理。事实上，.NET 线程池经过精心调整，具有高可扩展性（动态分配和退出线程）以及低延迟（它有一个最大阈值，允许请求在继续并开始之前变得过时）一个新线程以确保保留吞吐量）。

您已经打赌 .NET 已经成为一个可靠的平台，并且我们非常重视 .NET 中的线程池。

因此，有人可能会问，问题可能出在 Wait() 调用上……为什么他们一开始就使用阻塞等待？

答案是，有时你真的不得不这样做。例如，Main() 方法的 .NET 约定是当 Main() 方法返回时程序终止。或者...换句话说，Main() 方法会阻塞，直到程序完成。

其他事物（例如接口契约或虚拟方法契约）通常有特定的承诺，即在该方法返回之前执行某些事情。除非您的接口或虚拟方法返回一个任务...您可能需要对调用的任何异步 API 进行一些阻止。在这种情况下，这实际上违背了异步的目的......但也许您可以从不同代码路径中的异步中受益。

因此，对于返回异步任务的 API 提供程序，通过使用ConfigureAwait(false)，您可以帮助确保返回的任务没有任何意外的隐式依赖项（例如，UI 消息循环仍在主动泵送）。包含的依赖项越多，API 就越好。

希望这有帮助！

Answer 3

我认为目前 CTP 还没有最佳实践。

您可以提供这两种方法，但您应该问自己：
异步调用方法有意义吗？

我只会将其限制为耗时的方法。如果您需要使另一个方法异步，而该方法没有返回任务的方法，您仍然可以围绕该方法创建一个小包装器。