async 和 await 是否专门用于基于 GUI 的异步编程? [英] Is async and await exclusively for GUI-based asynchronous programming?

问题描述

我一直在阅读有关 C# 中新的 async 和 await 运算符的信息，并试图弄清楚它们在哪些情况下可能对我有用.我研究了几篇 MSDN 文章，以下是我在字里行间阅读的内容:

I've been reading about the new async and await operators in C# and tried to figure out in which circumstances they would possibly be useful to me. I studied several MSDN articles and here's what I read between the lines:

您可以将 async 用于 Windows 窗体和 WPF 事件处理程序，因此它们可以在执行大量操作时执行冗长的任务而不会阻塞 UI 线程.

You can use async for Windows Forms and WPF event handlers, so they can perform lengthy tasks without blocking the UI thread while the bulk of the operation is being executed.

async void button1_Click(object sender, EventArgs e)
{
    // even though this call takes a while, the UI thread will not block
    // while it is executing, therefore allowing further event handlers to
    // be invoked.
    await SomeLengthyOperationAsync();
}

使用 await 的方法必须是 async，这意味着在代码中某处使用任何 async 函数最终会强制所有方法进入从 UI 事件处理程序到最低级别的 async 方法的调用顺序也是 async.

A method using await must be async, which means that the usage of any async function somewhere in your code ultimately forces all methods in the calling sequence from the UI event handlers up until the lowest-level async method to be async as well.

换句话说，如果您使用普通的旧 ThreadStart 入口点(或具有旧 static int Main(string[] args))，那么您就不能使用 async 和 await，因为在某一时刻您必须使用 await，并使使用它的方法 async，因此在调用方法中，您还必须使用 await 并使其成为 async 等等.但是一旦到达线程入口点(或 Main())，就没有调用者可以让 await 控制权.

In other words, if you create a thread with an ordinary good old ThreadStart entry point (or a Console application with good old static int Main(string[] args)), then you cannot use async and await because at one point you would have to use await, and make the method that uses it async, and hence in the calling method you also have to use await and make that one async and so on. But once you reach the thread entry point (or Main()), there's no caller to which an await would yield control to.

所以基本上你不能在没有使用标准 WinForms 和 WPF 消息循环的 GUI 的情况下使用 async 和 await.我想这一切确实有道理，因为 MSDN 声明 async 编程并不意味着多线程，而是使用 UI 线程的空闲时间；当使用控制台应用程序或具有用户定义入口点的线程时，需要多线程来执行异步操作(如果不使用兼容的消息循环).

So basically you cannot use async and await without having a GUI that uses the standard WinForms and WPF message loop. I guess all that makes indeed sense, since MSDN states that async programming does not mean multithreading, but using the UI thread's spare time instead; when using a console application or a thread with a user defined entry point, multithreading would be necessary to perform asynchronous operations (if not using a compatible message loop).

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

My question is, are these assumptions accurate?

推荐答案

所以基本上你不能在没有使用标准 WinForms 和 WPF 消息循环的 GUI 的情况下使用 async 和 await.

So basically you cannot use async and await without having a GUI that uses the standard WinForms and WPF message loop.

这绝对不是.

在 Windows 窗体和 WPF 中，async/await 具有在您等待的异步操作完成时返回到 UI 线程的便利属性，但这不会这并不意味着这是它的唯一目的.

In Windows Forms and WPF, async/await has the handy property of coming back to the UI thread when the asynchronous operation you were awaiting has completed, but that doesn't mean that's the only purpose to it.

如果异步方法在线程池线程上执行 - 例如在 Web 服务中 - 然后继续(异步方法的其余部分)将简单地在任何线程池线程中执行，并适当保留上下文(安全性等).这对于减少线程数量仍然非常有用.

If an asynchronous method executes on a thread-pool thread - e.g. in a web service - then the continuation (the rest of the asynchronous method) will simply execute in any thread-pool thread, with the context (security etc) preserved appropriately. This is still really useful for keeping the number of threads down.

例如，假设您有一个高流量的 Web 服务，它主要代理对其他 Web 服务的请求.它大部分时间都在等待其他事情，无论是由于网络流量还是其他服务(例如数据库)的真实时间.您不应该为此需要大量线程 - 但是通过阻塞调用，您自然会为每个请求创建一个线程.使用 async/await，你最终会得到很少的线程，因为很少有请求实际上需要在任何时间点为它们执行任何工作，即使有很多的请求飞行中".

For example, suppose you have a high traffic web service which mostly proxies requests to other web services. It spends most of its time waiting for other things, whether that's due to network traffic or genuine time at another service (e.g. a datbase). You shouldn't need lots of threads for that - but with blocking calls, you naturally end up with a thread per request. With async/await, you'd end up with very few threads, because very few requests would actually need any work performed for them at any one point in time, even if there were a lot of requests "in flight".

问题在于，使用 UI 代码最容易演示 async/await，因为每个人都知道正确使用后台线程或在 UI 线程中做太多工作的痛苦.这并不意味着它是该功能唯一有用的地方 - 远非如此.

The trouble is that async/await is most easily demonstrated with UI code, because everyone knows the pain of either using background threads properly or doing too much work in the UI thread. That doesn't mean it's the only place the feature is useful though - far from it.

各种服务器端技术(例如 MVC 和 WCF)已经支持异步方法，我希望其他技术也能效仿.

Various server-side technologies (MVC and WCF for example) already have support for asynchronous methods, and I'd expect others to follow suit.

这篇关于async 和 await 是否专门用于基于 GUI 的异步编程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！