我很好奇异步等待线程的内部结构。
每个人都说异步在性能方面要好得多，因为它释放了等待对长时间异步调用的响应的线程。 好的，我明白了。
但让我们考虑一下这种情况。
我有一个异步方法 A 在数据库上执行异步操作。 数据库的api公开函数BeginQuery和事件QueryCompleted。 我用任务包装了它们(使用 TaskCompletionSource)。
我的问题是调用 BeginQuery 和触发事件 QueryCompleted 之间到底发生了什么。
我的意思是 - 不需要派生某种工作人员来触发事件吗？在非常低的级别上，它一定是某个同步循环正在阻止线程从 db 读取结果。
我想任何异步调用都必须生成一个线程来实际处理响应(可能在驱动程序代码的低级 c++ 循环中等待它)。
所以我们唯一的“收获”是当其他线程正在工作时调用者线程可以被释放。
调用异步方法是否总是创建一个新的工作线程？
谁能证实我的理解？
最佳答案
Everyone states that async is so much better in case of performance, because it frees threads that are waiting for a response to a long asynchronous call.
是也不是。 async 背后的要点是释放调用线程。在 UI 应用程序中，async 的主要好处是响应能力，因为 UI 线程被释放了。在服务器应用程序中，async 的主要好处是可扩展性，因为请求线程可以腾出时间来处理其他请求。
So our only "gain" is that the caller thread can be freed when some other thread is doing its work. Does always calling an asynchronous method is creating a new worker thread?
没有。在操作系统级别，所有 I/O 都是异步的。当底层异步 I/O 正在进行时，同步 API 会阻塞线程。我最近在博客文章中写了这个:there is no thread .
关于c# - 异步等待线程内部，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21879606/