异步等待的极简实现

Question

试图理解为什么 .NET 以他们的方式实现 async-await。

当更改一段简单的代码以使用 async-await 时，似乎最不需要的工作就是使用 async-await 指令标记调用和被调用的方法：

private async void OnGuiClick(object sender, EventArgs args)
{
  textBox1.Text = await Work();
}

private async Task<string> Work()
{
  await Task.Delay(2000);
  return "Result";
}

为什么.NET 坚持两者？ 即用一个关键字指定一个表达式会很好，必须立即在工作线程上异步评估表达式 - 而调用 GUI 线程被释放以执行其他任务，但将再次连接以执行剩余代码一次工作线程完成。

是否有更简单或更好的方法来分配工作线程来处理 Work 方法，然后自动（无需求助于 Invoke(...)）确保相同的调用 GUI 线程处理结果？ 为什么不这样：

private void OnGuiClick(object sender, EventArgs args)
{
  textBox1.Text = <'some async directive'> Work();
}

private string Work()
{
  Thread.Sleep(2000);
  return "Result";
}

(MSDN documentation 声明如果目标不包含 await 语句，编译器将同步执行代码 - 但那有什么意义呢？ - 当然 await async 关键字仅用于异步使用。那为什么要这样做复杂，而不是使用单个指令？）

Answer 1

你提出了一个很好的例子——我相信编译器只需要“await”关键字。我不认为它关心“异步”修饰符。

然而，编译器坚持你用“async”修饰符标记你的方法是一件好事 - 它允许你检查一个方法是否会同步/异步运行而不必深入研究其实施。它还告诉您是否必须/能够await 它。我相信这些是强制使用这两个关键字的原因，而不仅仅是一个。

类似的情况是：为什么您需要使用“public”访问修饰符标记接口实现方法，即使它不能是私有/内部/受保护/受保护的内部？看起来是多余的吧？但是，它确实增加了可读性。

Answer 2

我有一个关于这个主题的blog post。主要原因是为了向后兼容（允许 await 关键字成为 contextual 关键字）。阅读代码时，将async 关键字作为指标也很好。

另请参阅有关该主题的 Eric Lippert's blog post，以及他的 comments on another post、Channel9、MSDN forums 和 right here on SO。

Answer 3

指定async 关键字直接暗示该方法的内部必须从头开始重写以支持async/await 模型。您可能知道，生成的 IL 看起来与您的原始方法不太一样。您可能会争辩说这种重写也可能是隐含的，但在某种程度上明确允许这种情况发生是有意义的。

另一方面，你有一个正确的观点：当使用 yield 关键字隐式实现 IEnumerable 时会发生类似的事情，这也与 async 模型有点相似，因为它也创建了一个状态机。并且不存在在此类方法之前放置 enumerated 关键字的要求。