翻译 异步I/O不会创建新的线程

异步I/O不会创建新的线程

本文翻译自 Stephen Cleary 的 [There is No Thread] 原文地址 https://blog.stephencleary.com/2013/11/there-is-no-thread.html

这是异步编程最基本的事实 : 异步I/O不会创建新的线程

反对这个事实的人很多,他们对此的看法是 "如果我await一个操作,那么一定会有一个线程正在等待，它可能是一个线程池的线程,或者是操作系统线程,或者是某个设备的驱动程序"

不用关注这些看法, 只需要记住如果异步操作是纯粹的(方法全是async),那么就不会产生新的线程

不过这么一个简单的结论显然并不能够让他们信服,下面就看看异步到底发生了什么

让我们跟踪一个异步操作直到硬件层面,注：Net部分和设备驱动部分将被简化描述 (因为细节太多了)

下面是一个通用的写入操作 (例如 文件、网络、USB面包机等等)

private async void Button_Click(object sender, RoutedEventArgs e)
{
  byte[] data = ...
  await myDevice.WriteAsync(data, 0, data.Length);
}

我们已经知道在await的时候UI线程不会被阻塞，那么问题来了: 是否是UI线程创建了另外一个线程杀了祭天换来了自己的自由....

关于UI线程是否犯下这一恶行,让我们深入推断一下

首先 ： 看看类库 (BCL的代码) 假设 WriteAsync 是使用.Net中标准的异步方式平台调用(P/Invoke)I/O系统,这是一个基于异步方式的I/O，所以这会在设备的底层上启动一个win32异步方式I/O操作句柄

然后操作系统会告诉设备驱动程序进行写操作,代码实现是构造出表示写请求的对象,这个对象称为I/O请求包(IRP)

设备驱动程序接收到IRP后会向设备发出一个命令来写出数据,如果这个设备支持直接内存存取技术(DMA),只需将缓冲区地址写入设备寄存器即可,设备驱动程序能做到将IRP标记为 "pending" 后交把控制权交还操作系统

在这里发现了真相的核心所在 : 在处理IRP时,设备驱动是不允许阻塞的。这意味着如果IRP不能立即完成,那么它必须异步处理,即使对于同步的api也是如此！在设备驱动级别,所有(有意义)的请求都是异步的

引用书籍里的知识 "无论是什么类型的I/O请求,应用程序向驱动程序发出的I/O操作都是异步执行的"

在IRP为 "pending" 时,操作系统返回到类库,类库将未完成的任务返回到应用程序的按钮单击事件方法,该方法挂起async方法,UI线程继续执行

我们已经跟踪请求到系统的尽头 直到物理设备

现在写入操作正在飞快的进行中,有多少个线程正在处理它?

答案是没有

没有设备驱动程序线程、操作系统线程、BCL线程或者写在处理写操作的线程池线程(