我一直在学习异步/等待的使用，我想我理解了底层的概念。然而，大多数关于 async/await 的 Channel 9 教程、MSDN 文章和 Stack Overflow 答案都使用基于 GUI 的应用程序（Windows 窗体应用程序）来演示 async/await 的强大功能。
但是，我注意到基于 UI 线程的应用程序与常规 ThreadPool 基于线程的应用程序（例如 ASP.NET Web 应用程序、控制台应用程序等）中使用 async/await 存在根本区别。
由于在基于 UI 线程的应用程序中，UI 线程始终可用（除非进程显式停止或被 Windows 停止），因此负责执行任何异步方法中“await”之后的代码的 ThreadPool 线程将保证找到UI 线程将结果发回（如果有）。
但是，在控制台应用程序或 ASP.NET Web 应用程序中，主线程（在控制台应用程序中）或 HTTP 请求（在 ASP.NET Web 应用程序中）必须等待（在某个时间点），直到所有异步操作都完成为止。完全的。因此，如果没有其他工作需要处理，在异步方法调用之后的某个地方应该有 .Wait() 和 .Result 调用。
这种理解正确吗？我并不质疑异步对于 I/O 绑定或网络绑定操作的好处（我了解它将如何提高应用程序的可扩展性）。
由于在基于 UI 线程的应用程序中，UI 线程始终可用（除非进程显式停止或被 Windows 停止），因此负责在任何异步方法中的“await”之后执行代码的 ThreadPool 线程将保证找到 UI线程将结果发回（如果有）。
这有点混乱。没有迹象表明ThreadPool根本就需要线程。
由可等待的实现来确定在哪里运行延续，但通常是当前的同步上下文用于计算在哪里运行它：
- 在控制台应用程序中，有is没有同步上下文，因此线程池线程用于延续。
- 在 Windows 窗体应用程序中，当您在 UI 线程上运行时，同步上下文将在 UI 线程上执行代码...因此延续将在那里执行（除非您使用
ConfigureAwait， ETC...）
- 在 ASP.NET 应用程序中，存在特定于 ASP.NET 本身的同步上下文。
See Stephen Cleary 的 MSDN 文章 http://msdn.microsoft.com/en-us/magazine/gg598924.aspx更多细节。
目前尚不清楚您稍后提出的有关必须打电话的问题是什么意思Wait or Result在 ASP.NET 或控制台应用程序中...在这两种情况下may是必需的，但同样也可能不是。这取决于你真正在做什么。不要忘记，即使是控制台应用程序也可以启动自己的线程并执行各种其他操作 - 例如，您可以在控制台应用程序中编写 HTTP 服务器......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
