消毒异步方法c#的最佳方法答案

【问题标题】：Best way to sterilise async methods c#消毒异步方法c#的最佳方法
【发布时间】：2019-02-28 00:49:41
【问题描述】：

在花了太多时间试图解决异步/等待地狱之后，我们试图获得一个标准，当我们必须在我们无法控制的库上调用异步方法以及没有非异步的情况下方法提供并从我们的代码中获取异步。

我不想讨论它的优点，我确信对于某些人来说 async/await 有效，只是调用任何 async 方法并且不会出现死锁等的万无一失的方法。

会

public someObject SomeFunction(string parameter)
{
    return Task.Run(() => 3rdPartyLib.SomeFunctionAsync(parameter)).Result;
}

和

public void SomeMethod()
{
    return Task.Run(() => 3rdPartyLib.SomeMethodAsync()).Wait;
}

做这份工作？我需要配置等待（假）吗？异常会正常工作吗？

【问题讨论】：

答案是没有。从字面上看，您所做的任何事情都会有潜在的问题。这就是为什么你首先不需要把自己放在那个位置上。如果有一个简单的万无一失的解决方案始终有效，您就不会经常有人告诉您为什么不应该这样做，因为没有必要。
@Servy 我同意，我已经尝试找到具有同步方法的替代库

标签： c# async-await

【解决方案1】：

好吧，也写synchronous wrappers for asynchronous methods is an antipattern。

也就是说，有一个variety of hacks covered in my Brownfield Async article。您建议的那个 - “线程池 hack” - 将起作用除非第三方库需要使用当前上下文。例如，如果它是一个希望在可以访问 UI 控件的场景中运行的方法，或者如果它希望拥有HttpContext.Current。 大多数库不需要这个，所以这个 hack 对他们有用。

没有什么技巧可以在任何地方、任何情况下都奏效。

您不需要ConfigureAwait(false)。没有要配置的await。

对于例外情况，您应该使用GetAwaiter().GetResult() 而不是Result 和Wait()。这可以防止异常被包裹在 AggregateException 中。

【讨论】：

斯蒂芬，我向你致敬，因为你在这一点上重复了很多次之后仍然保持清醒和高效：D
在我阅读您之前引用的链接之前，我总是通过同步包装器很好。可能使我免于许多 hard 错误。好链接
非常感谢那篇棕地异步文章，非常好，因为我们几乎从不受限于 IO 并且非常受限于 CPU，我怀疑这就是我们遇到问题的原因，很遗憾有这么多.net 正在强制异步/等待
@dibs487: async 不适用于受 CPU 限制的代码；如果开发人员尝试在不需要的地方使用async，则会导致问题。 async 非常适合 I/O，但与受 CPU 限制的混合需要一些注意。我在Task.Run etiquette 上有一个博客系列，部分解决了这个问题。