c# - 异步鸡和蛋故事的最佳解决方案

Question

我一直在将异步最佳实践应用到我所有的库中。基本上它意味着:

1. 只有真正异步时才使用异步(库不应该撒谎)
2. 当且仅当您有更快且不会死锁的同步方法时，才定义同步方法。
3. 用 Async 后缀所有异步方法

我在一个本质上是同步的库上工作。这意味着它只有同步方法。如果用户想要在与 UI 线程不同的线程上运行工作，他们可以使用 Task.Factory(调用者的责任)自行完成。

但是，在处理程序/方法/扩展点内部，我们希望向用户显示一个消息框。这是一个异步方法(例如，WinRT ShowDialogAsync)。然后这为我们提供了以下选项:

A.将所有内容移至异步(因此我们可以选择在我们的处理程序中使用 await 并且不阻止任何内容)。

public async Task MyMethodAsync()
{
    await _messageService.ShowAsync();
}

优点是用户可以添加异步方法而无需使用.Wait()。缺点是我们作为一个库在说谎(它不是真正的异步)。

我考虑过让一切 异步，但我认为这也不是一个好主意。它会让所有图书馆撒谎，但要准备好它们以防我们需要它。请记住，开箱即用地使所有内容异步也会对性能产生(小的)影响。

B.在需要用户输入的处理程序中，调用 .Wait()

public void MyMethod()
{
    _messageService.ShowAsync().Wait();
}

优点是这将允许我们在同步方法中使用异步代码。但是......它永远不会从 UI 线程调用，因为 _messageService 分派(dispatch)到 UI 线程(但它不能这样做，因为它仍在等待方法，导致死锁)。当在 Task.Factory.Run block 内使用时，此方法将起作用(但责任由最终用户承担):

await Task.Factory.Run(() => MyMethod());

问题

我觉得两者各有利弊，但你会选择什么？让库位于 (A) 还是只允许从后台线程调用方法 (B)？或者也许还有其他我监督过的选项。

如果我选择 A，这意味着每当用户请求将方法转换为异步签名方法时，我每次都必须升级主要版本(因为这实际上是一个重大更改)。

Answer 1

Define a synchronous method if and only if you have a faster synchronous method that won’t dead lock.

我会说“如果您有同步工作要做，请定义一个同步方法”。不管它有多快。调用者有责任确定它是否太慢并且他们需要使用 Task.Run。

However, inside a handler / method / extensibility point

如果这是一种观察者类型的可扩展性，请考虑仅使用事件或可观察对象。

但是，听起来您更想要一种策略类型的可扩展性，您的调用代码必须等待和/或根据回调的结果更改其行为。

I have considered making everything async, but I don't think that's a good idea either.

Async all the way 是一个准则，而不是一个严格的命令。它绝对适用于 99% 的情况，但这可能是异常(exception)之一。我会尽量不要仅仅为了可能的异步策略模式而使库异步；我会先调查其他扩展的可能性。如果您将 Strategy 回调视为依赖项(库将是异步的，因为它的依赖项(可能)是异步的)，那么使库异步是有道理的。

正如您所发现的，没有一种干净的方法可以实现异步同步。有一些不同的 hack(例如从后台线程阻塞)，但您首先需要决定是否需要从 UI 线程调用您的库。

如果这样做，那么只有两个选择:使库异步，或使用嵌套的消息循环。我强烈避免嵌套的消息循环，尤其是在图书馆中；我只是为了完整起见才提到它。

如果您可以对用户施加仅从非 UI 线程调用库的要求，那么您可以应用其他 hack。例如，阻塞后台线程。

抱歉，没有简单的解决方案。

就我个人而言...如果库需要异步策略，那么我会倾向于使库异步。但这确实取决于它是什么类型的库，是否存在向后兼容性问题等。我首先要研究的是不同类型的扩展点。