异步和等待是否仅用于基于GUI的异步编程？

28 浏览
0 Comments

异步和等待是否仅用于基于GUI的异步编程？

我一直在阅读关于C＃中新的async和await操作符的内容，并试图弄清楚在哪种情况下它们可能对我有用。我研究了几篇MSDN文章，以下是我在字里行间读到的内容：

您可以在Windows Forms和WPF事件处理程序中使用async，以便它们可以执行耗时任务而不会阻塞UI线程，同时执行操作的大部分内容。

async void button1_Click(object sender, EventArgs e)
{
    // 即使此调用需要一段时间，UI线程也不会阻塞
    // 在执行时，从而允许调用其他事件处理程序。
    await SomeLengthyOperationAsync();
}

使用await的方法必须是async，这意味着您的代码中任何地方使用async函数最终都会强制调用序列中从UI事件处理程序到最低级async方法的所有方法也必须是async。

换句话说，如果您使用普通的ThreadStart入口点创建线程（或使用好旧的static int Main(string[] args)创建控制台应用程序），那么您无法使用async和await，因为在某个地方您将不得不使用await，并使使用它的方法成为async，因此在调用方法中您还必须使用await并使其async，依此类推。但是一旦到达线程入口点（或Main()），就没有调用者可以将await控制权传递给。

因此，基本上，没有使用标准WinForms和WPF消息循环的GUI，您无法使用async和await。我想所有这一切确实有道理，因为MSDN表明async编程并不意味着多线程，而是利用UI线程的空闲时间；当使用控制台应用程序或具有用户定义入口点的线程时，执行异步操作将需要使用多线程（如果不使用兼容的消息循环）。

我的问题是，这些假设准确吗？

0