异步和等待-控制台，Windows窗体和ASP.NET之间的区别 [英] Async and await - difference between console, Windows Forms and ASP.NET

问题描述

我一直在进行异步/等待使用方面的教育，我认为我理解了底层概念。但是，大多数Channel 9教程，MSDN文章和有关异步/等待的堆栈溢出答案都使用基于GUI的应用程序（Windows窗体应用程序）来演示异步/等待的功能。

I have been educating myself on async / await use and I think I understood under-the-hood concept. However, most of Channel 9 tutorials, MSDN articles and Stack overflow answers on async / await use GUI-based applications (Windows Forms application) to demonstrate the power of async / await.

但是，我注意到在基于UI线程的应用程序和常规的基于ThreadPool线程的应用程序（例如ASP.NET Web应用程序，控制台应用程序等）中使用异步/等待的根本区别。

However, I noticed a fundamental difference in async / await use in a UI-thread based application vs. regular ThreadPool thread-based applications (e.g. ASP.NET Web Application, Console Application, etc.).

由于在基于UI线程的应用程序中，UI线程始终可用（除非进程已显式停止或被Windows停止），因此ThreadPool线程负责在等待后执行代码。任何异步方法，都将确保找到UI线程以将结果回传（如果有的话）。

Since, in UI thread-based application, the UI thread is always available (unless the process is stopped explicitly or by Windows), so the ThreadPool thread responsible for executing the code after "await" in any async method, will guarantee to find the UI thread to post the results back (if any).

但是，在控制台应用程序或ASP.NET Web应用程序中，主线程（在控制台应用程序中）或HTTP请求（在ASP.NET Web应用程序中）必须（在某个时间）等待，直到所有异步操作完成。因此，如果没有其他需要处理的地方，在Async方法调用之后的某个地方应该有.Wait（）和.Result调用。

However, in a console application or ASP.NET Web application, the main thread (in a console application) or the HTTP request (in an ASP.NET web application) must be waiting (at one point of time) until all async operations are completed. So there should be .Wait() and .Result call somewhere after the Async method call, if there is nothing more to work on.

这种理解正确吗？我不怀疑对I / O绑定或网络绑定操作进行异步的好处（我知道它会增加应用程序的可伸缩性）。

Is this understanding correct? I am not questioning the benefit of having async for I/O bound or network-bound operations (I understand how it's going to increase application scalability).

推荐答案

由于在基于UI线程的应用程序中，UI线程始终可用（除非进程已显式停止或被Windows停止），因此ThreadPool线程负责在任何异步方法中的等待，将保证找到UI线程以将结果发回（如果有的话）。

Since, in UI thread based application, the UI thread is always available (unless the process is stopped explicitly or by Windows), so the ThreadPool thread responsible for executing the code after "await" in any async method, will guarantee to find the UI thread to post the results back (if any).

困惑。没有迹象表明完全需要 ThreadPool 线程。

This is slightly confused. There's no indication that a ThreadPool thread will be required at all.

要由等待的实现来确定运行延续，但是通常使用当前的同步上下文来计算在哪里运行：

It's up to the awaitable implementation to determine where to run the continuation, but normally the current synchronization context is used to work out where to run it:

• 在控制台应用程序中，没有同步上下文，因此使用线程池线程进行延续。


• 在Windows Forms应用程序中，当您在UI线程上运行的同步上下文是一个将在UI线程上执行代码的同步上下文...因此继续执行在此执行（除非您使用 ConfigureAwait 等）。


• 在ASP.NET应用程序中，有一个特定于ASP.NET本身的同步上下文。

• In a console application, there is no synchronization context, so a thread pool thread is used for the continuation.
• In a Windows Forms application, when you're running on the UI thread the synchronization context is one which will execute code on the UI thread... so the continuation executes there (unless you use ConfigureAwait, etc...)
• In an ASP.NET application, there's a synchronization context specific to ASP.NET itself.

有关更多详细信息，请参见 Stephen Cleary的MSDN文章。

See Stephen Cleary's MSDN article for more details.

尚不清楚您迟到的意思关于在ASP.NET或控制台应用程序中必须调用等待或结果的问题……在两种情况下，它 是必需的，但同样可能不是必需的。这取决于您的实际工作。不要忘记，即使是控制台应用程序也可以启动自己的线程并执行其他各种操作-例如，您可以在控制台应用程序中编写HTTP服务器...

It's not clear what you mean by your later question about having to call Wait or Result in ASP.NET or a console app... in both scenarios it may be required, but equally it may not be. It depends on what you're doing really. Don't forget that even a console app can start its own threads and do all kinds of other things - you can write an HTTP server in a console app, for example...

这篇关于异步和等待-控制台，Windows窗体和ASP.NET之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！