在控制台或Web应用程序中使用异步/等待 [英] Use of async/await in console or web apps

问题描述

据我了解，C#中的async/await功能将await调用之间的段拆分为回调方法，这些回调方法在每个等待的方法在单独的工作线程上返回后在调用线程上运行.在等待时间内，调用线程是空闲的".必须通过某种事件循环在调用线程上计划回调.

As I understand it, the async/await feature in C# splits up the segments between await calls into callback methods that run on the calling thread after each awaited method has returned on a separate worker thread. The calling thread is "free" during the waiting time. The callback must be scheduled on the calling thread through some sort of event loop.

此事件循环仅存在于Windows窗体或WPF之类的GUI应用程序中.释放此循环可确保UI在长时间操作期间仍对其他用户交互保持响应.

This event loop only exists in GUI applications like Windows Forms or WPF. Freeing this loop makes sure the UI remains responsive for other user interaction during long operations.

控制台应用程序和Web应用程序(ASP.NET)没有此类事件循环，因此此回调机制不起作用.但是话又说回来，它们没有事件循环，因为它们不需要事件循环.没有用户试图在任何时候与正在运行的程序进行交互，期望立即得到反馈.因此，无需为此释放调用线程.该操作使用多少线程无关紧要，只有在最后一位完成后才返回.

Console apps and web apps (ASP.NET) do not have such event loops, so this callback mechanism doesn't work. But then again, they do not have an event loop because they don't need one. There is no user trying to interact with the running program at any time, expecting immediate feedback. So there's no need to free the calling thread for that. It doesn't matter how many threads the operation uses, it only returns after the last bit is done.

那么在控制台和Web应用程序中async和await的用途是什么，或者通常是任何种类的非交互式代码，例如Windows服务?与简单的同步呼叫相比，这种方式有何不同或更有效率?

So what's the use of async and await in console and web apps, or any kind of non-interactive code in general, like for example Windows services? How is that different or more efficient compared to simple synchronous calls?

我正在设计一个供GUI和非交互式(服务和Web)程序使用的API，并且很难理解它在非GUI环境中的行为.

I'm designing an API that is used by GUI and non-interactive (service and web) programs and have a hard time understanding how it behaves in non-GUI environments.

推荐答案

使用async-await的要点是，当您到达第一个异步点(即第一个异步点)时，调用线程总是被释放await尚未完成的任务.

The point with async-await is that the calling thread is always freed up when you reach the first asynchronous point (i.e. the first await of an uncompleted task).

在UI应用程序中，您有一个SynchronizationContext，它会在等待之后将代码发布到UI线程，因为与UI交互的代码必须由UI线程执行，否则会出现异常.您可以使用ConfigureAwait(false)进行控制.

In UI apps you have a SynchronizationContext that posts the code after the awaits to the UI thread because code that interacts with the UI must be executed by the UI thread otherwise you'll get an exception. You can control that by using ConfigureAwait(false).

在控制台应用程序(和服务等)中没有这样的需求，因此代码可以在某些ThreadPool线程上运行.释放了调用线程(很可能也是ThreadPool线程)，并且可以在此期间执行其他类型的工作，而不是同步阻塞.因此，异步等待可提高可伸缩性，因为它可以在相同数量的线程上完成更多工作.

In console apps (and services, etc.) there's no such need, so that code runs on some ThreadPool thread. The calling thread (which is likely to be also a ThreadPool thread) was freed up and was able to do other kinds of work in the meantime instead of blocking synchronously. So async-await improves scalability as it enables doing more work with the same amount of threads.

这篇关于在控制台或Web应用程序中使用异步/等待的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！