【发布时间】:2020-11-08 05:31:13
【问题描述】:
我一直在自学异步/等待的使用,我想我理解了幕后概念。但是,大多数 Channel 9 教程、MSDN 文章和关于 async/await 的 Stack Overflow 答案都使用基于 GUI 的应用程序(Windows 窗体应用程序)来展示 async/await 的强大功能。
但是,我注意到在基于 UI 线程的应用程序与基于常规 ThreadPool 线程的应用程序(例如 ASP.NET Web 应用程序、控制台应用程序等)中使用 async/await 的根本区别。
由于在基于 UI 线程的应用程序中,UI 线程始终可用(除非进程显式停止或被 Windows 停止),因此负责在任何异步方法中“等待”之后执行代码的 ThreadPool 线程将保证找到 UI 线程以将结果发回(如果有)。
但是,在控制台应用程序或 ASP.NET Web 应用程序中,主线程(在控制台应用程序中)或 HTTP 请求(在 ASP.NET Web 应用程序中)必须等待(在某个时间点),直到所有异步操作完成。所以在 Async 方法调用之后应该有 .Wait() 和 .Result 调用,如果没有更多工作要做的话。
这种理解正确吗?我并不质疑为 I/O 绑定或网络绑定操作使用异步的好处(我了解它将如何提高应用程序的可扩展性)。
【问题讨论】:
-
在 ASP.Net 和异步上 - 查看 Using Asynchronous Methods in ASP.NET MVC - 所有适当的等待已经为您准备好,您自己的代码不需要调用
Wait/Result。跨度> -
@AlexeiLevenkov - 在 MVC 中(也在 Windows 窗体应用程序、ASP.NET Web 窗体应用程序中)有一种方法可以使事件处理程序“异步”并且 .NET 框架知道等待一些异步操作要完成。在控制台应用程序中,主线程不能是异步的,它必须等待一些异步操作(甚至是触发和忘记类型的异步操作)在返回之前完成。
标签: c# .net asynchronous async-await