写在前面

• 本文首发于 https://debugwar.com/article/Multi-Thread-Illusion-Analyze-of-a-Fake-Multi-Thread-Situation， 授权转载到看雪论坛，转载请注明出处。
• 看雪的这个MarkDown的系统与我的写作系统有点冲突，排班可能会有问题，可以点上面的连接去看原文获得更好地排版体验。
• Linux的输入法你懂的，可能会有错字别字，大家多包涵~

正文

多线程是我们日常开发中经常使用到的技巧，一般使用多线程的目的是为了加快某些操作的速度从而给用户更好的使用体验。近期笔者就遇到了一个多线程相关问题，本来是想加速某些功能但是最总效果却和单线程一样，后来经过排查终于定位到了原因并解决了问题，也同时有了此文。

背景

目前笔者部门正在开发一个程序，其中有一块功能需要和内核做数据交互。程序的界面如下图：

为了更好的用户体验，程序的设计逻辑是：当点击“内核”标签页下的各个子标签页时，每个子标签页将会开一个线程去调用DeviceIoControl函数和内核模块做交互。这样的话每个子标签页的数据加载是独立的，互不影响，在一定程度上会加快数据的获取速度。

根据上述设计，抽象出的编码如下（以伪代码表示）：

如果看到此处，你已经看出问题在哪里了，那么接下来就不用往下看了，因为所有必要的信息已经包含在上面的伪代码中。

问题现象

OK，有了上面的背景铺垫之后，接下来描述一下问题现象。

当前内核模块对各子标签页功能的处理速度有快有慢，我们不妨假设"Object"这个标签页很慢，需要60秒钟才能完成，"卸载模块"这个标签页很快， 5秒钟即可完成。

如果这个时候，我们先点击"Object"标签页， 那么此时其对应的subtab_woker_thread线程会被启动去请求数据。此时我们再点击"卸载模块"标签页，启动其对应工作线程去内核取数据。

这里暂停一下，各位请思考一下我们将会在几秒后看到"卸载模块"的数据？我们期望的答案是5秒，但正确答案应该是65秒。

上述答案也是程序实际的行为，在点击了一个比较耗时的子标签页之后再点击一个耗时很小的子标签页，则耗时很小的子标签页也需要等待很长时间后才会展示数据。

问题分析

从结果上看，虽然程序设计和编码上都是多线程同时工作的，但其实际效果依然是单线程的。是什么原因造成了这个结果呢？接下来我们通过调试器分析一下成因。

笔者使用的是双机调试环境，调试器是运行在内核模式下的，被调试机上运行我们本次的分析对象： QDoctor.exe。

首先在调试机上获取一下进程列表，以获得QDoctor的EPROCESS：

看一下QDoctor各个线程的状态：

可以看到，只有0460号线程是RUNNING状态，这个线程位于2号核上。看一下这个线程的堆栈状态：

从上面的第18行可见，此时这个线程正在执行位于constantine64+0xc231de处的指令，而constantine64模块即为我们的内核模块。换句话说，只有0460号线程是在真正干活的，而其他的“工作”线程却在偷懒，比如下面这个线程：

看一下上面这个线程在干嘛：

从IdealProcessor可知，此线程在1号核上运行（从0开始计数），按照道理来说应该和位于2号核的线程ffffc58fbbefd080不冲突才对，但是此线程在调用了nt!NtDeviceIoControlFile之后却偏偏进入了nt!KeWaitForSingleObject，而这次等待最终导致内核执行了线程切换（nt!KiSwapThread）。

从栈回溯来看，ffffc58fbbefe7c0线程进入等待的原因是nt!IopAcquireFileObjectLock尝试去拿一个文件对象的锁，实际情况是线程并没有拿到这个锁。

到这里再次暂停一下。如果各位看官看到这里想到了问题成因，那么说明你的基本功比较扎实哦~ ;)

那么nt!IopAcquireFileObjectLock尝试获取的这把锁是什么东西呢？根据对nt!IopXxxControlFile的逆向可知这把锁来自nt!IopAcquireFileObjectLock的第一个参数，其类型为_FILE_OBJECT指针：

那么看一下这个_FILE_OBJECT具体是个什么东西，根据调用堆栈可知第一个参数是：ffffc58f`bc07cef0，windbg观察一下：

找到了一个设备对象ffffc58f`bc4c9060，而这个设备对象为\FileSystem\QAXANTIROOTKIT，这个就是我们上文中提到的constantine64驱动创建的服务。

分析结论

结合本文一开始给出的程序工作流程伪代码，可知当前的工作流程是：

1. 入口函数打开由constantine64创建的服务，获得其句柄
2. 启动子标签页工作线程，并传入1中打开的句柄
3. 子标签页工作线程调用DeviceIoControl请求constantine64的对应功能
4. DeviceIoControl的内核例程调用nt!IopAcquireFileObjectLock尝试获取1中句柄对应文件对象的锁
5. 由于句柄是入口函数创建，属于共享资源，有其他RUNNING状态线程已经持有此设备，因此获取文件对象锁失败
6. 调用nt!KeWaitForSingleObject等待锁解除锁定状态
7. 线程进入Alertable WAIT状态
8. 系统进行线程切换

因此，只有第5步中RUNNING状态线程释放占用的锁之后，其他工作线程才能继续工作。回到一开始我们假设的场景中，即只有"Object"的工作线程在60s的工作完成后，"卸载模块"的工作线程才能拿到这把锁，然后用5秒钟把活干完。这也是上文中正确答案65秒的由来。

虽然我们在设计上是多线程的，但是由于对临界资源的使用不当导致最终还是单线程线性工作。其实，在微软的文档里，已经明确告诉我们了。根据CreateFile的API文档，其dwFlagsAndAttributes参数的描述（参考1）:

还记得一开始我们是如何创建设备句柄的吗？

并没有指定OVERLAPPED，因此所有对这个句柄的请求都会是同步IO，这也是为何内核要获取锁的原因。

解决问题

通过上文的分析，我们自然想到可以借助OVERLAPPED实现异步IO。但是这样是有代价的——这意味着R3程序和R0程序都需要作出对应修改，且R0程序还需要借助开启额外的内核线程来完成异步请求的处理，这样会导致本来一个功能对应的后台线程数翻倍。

那么，既然我们R3程序已经开了子线程来处理当前子标签页的请求了，R0程序能不能利用这个子线程，在当前子线程的上下文中完成对应的内核部分工作呢？答案当然是肯定的，而且对应修改也非常简单，重写后的程序工作代码（伪）如下：

如各位所见，仅需要简单粗暴的将创建设备对象句柄的代码移到工作线程内使其变成一个局部变量即可。

这里又要暂停一下了，不知道看到这里各位有没有和我一样的疑问，这个疑问关键词是：引用计数。

既然我们的所有子线程都是创建自\\.\KernelModule的句柄，那么内核层面不应该是使\\.\KernelModule文件对象的引用计数不停的增加吗？这样的话，由于当前代码我们依然没有使用OVERLAPPED参数，其创建的文件对象又都是一个，那么依然应该是假的多线程才对啊。

带着这个疑问，我们有必要继续深挖一下内核的工作模式。

CreateFile函数流程简要分析

CreateFile函数应该是我们日常编程中使用频率最高的函数之一了，因此对他有必要深入理解一下。通过对WRK的研究，我们可以得出如下内核调用路径：

可见最后会调用到OpbLookupObjectName函数，这个函数本身比较复杂，但是其核心却及其简单：从Object Directory中查找对应名称的对象，然后调用对象的ParseProcedure函数用于生成待创建文件对象。由于本文中我们面对的是Device类型的设备，所以我们关注Device类型对象的ParseProcedure函数，而对Device类型对象的创建工作位于IoCreateObjectTypes函数中，在这里我们可以得到系统默认的ParseProcedure函数值：

由上图可知，Device类型对象的ParseProcedure默认函数为IopParseDevice。而通过对WRK中IopParseDevice的研究，其重点在于对ObCreateObject的调用：

简化后的IopParseDevice逻辑：

可见当 op->QueryOnly 和 op->DeleteOnly 均为FALSE时，realFileObjectRequired为TRUE，此时需要创建对应的文件对象。而根据OPEN_PACKET的定义：

结合重写后的程序逻辑，目前我们打开对象的操作必然不是 查询、删除 操作，因此一定会走到ObCreateObject的逻辑，即当CreateFile的目标为设备（或设备的软连接）时，一定会（查询、删除除外）产生文件对象创建操作。

由于文件对象都是新创建的，因此本节一开始的认知——其创建的文件对象又都是一个——是不正确的，实际上每个子线程调用CreateFile创建的句柄后面都对应一个新创建的同步IO文件对象，由于是新创建的因此不会产生一开始无法获取到锁的问题（因为只有当前子线程在用这个文件对象）。这也是本篇文章“假多线程”解决方案的根据。

DuplicateHandle

在实际编程中，还有一个和句柄相关的API即DuplicateHandle，通过跟踪这个函数的代码，发现从头到尾，都未调用到ObCreateObject函数，而是在进程PspCidTable中大量使用ObReference和ObDereference家族函数增减对象的引用计数：

因此我们可以得出结论DuplicateHandle函数并不会导致新对象的创建，其作用仅仅是在PspCidTable中新增一项并使新增的项目指向内核重已经存在的一个对象。

总结

纵观整个调试、分析过程，其实本文面对问题产生的原因本质上是因为不合理使用临界资源导致的，只不过是本文中涉及到的临界资源比较隐晦，虽然在微软的官方文档中有相关描述，但是在实际使用的过程中依然很容易忽略从而写出不符合预期的代码。

其实可以认为本文是针对同步IO与异步IO(参考2)的一个原理性分析，希望可以帮到大家。

参考

1. CreateFile API文档
2. Synchronous and Asynchronous I/O

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课