问题 在Console / Win服务应用程序中不需要ConfigureAwait(false),对吗?


我一直在用 async/await 有一段时间了,但最近深入研究,并阅读了许多最佳实践提示,默认情况下总是使用 ConfigureAwait(false) 防止死锁并提高性能。

我只是想确保我没有遗漏某些东西,当我认为这只适用于实际电流时 SynchronizationContext 要么 TaskScheduler 在玩,对吗?

如果我有一个响应消息/命令/等的Windows服务应用程序。异步地,它总是只使用默认的scheduler =可能与awaitable completed on相同的线程池线程将执行continuation,因此使用时不会出现死锁和性能差异 ConfigureAwait(false),对吗?

这不是我不能把它放在那里,但我非常讨厌噪音代码......


2771
2017-09-12 22:20


起源

您最好编写模块化的代码,并不关心它是在控制台,Windows服务,ASP.NET站点还是窗口项目中运行(所以是的,您应该将其放入,因为您的代码可以在它需要它的情况),但有时你知道它不会在那些情况下使用(所以不,你不应该把它放进去)。它是编码风格的问题。 - Scott Chamberlain


答案:


一般来说,这是事实。在控制台或服务方案中工作时,没有 SynchronizationContext 安装(默认) 所以 continueOnCapturedContext 选项 ConfigureAwait 将无效,这意味着您可以安全地删除它而不更改运行时行为。

但是,可能有例外情况,因此我经常建议您编写代码,包括 ConfigureAwait(false) 适当的时候。

即使在控制台或服务应用程序中包含它的主要优点是:

  1. 该代码稍后可在其他应用程序中重用。如果您选择重复使用此代码,则无需追踪因不包含此错误而产生的错误。
  2. 如果您碰巧安装(或使用安装的库)a SynchronizationContext 在运行时,方法的行为不会改变。

9
2017-09-12 22:26