关于驱动派遣函数的线程上下文的问题?

Question

  今天在网上看到这个问题, 自己也不明白, 在此请教, 希望高手给个详细一点的解释, 谢谢了, 问题如下:  想请教一个问题，看到这样一段描述。
  系统服务函数NtReadFile创建IRP_MJ_WRITE类型的IRP，然后它将这个IRP发送到某个驱动程序的派遣函数中。NtReadFile然 后去等待一个事件，这时当前线程进入“睡眠”状态，也可以说当前线程被阻塞住或者线程处于“Pending”状态。这里说当线程进入睡眠状态，那么线程就可能发生了切换吧，那其派遣函数又在哪个线程环境中执行的？似乎根据不同的IRP类型其派遣函数被调用的方式都不同？ 

Answer 1

这段话说的不够准确。IRP发给驱动程序的派遣函数后，有两种情况，一种是驱动程序立即处理并完成，然后返回，包括成功或失败；另一种情况是请求不能立即得到处理或者操作需要等待，此时驱动程序会将请求标记为Pending并返回，当前线程可以等待，也可以执行其它操作，前者是同步I/O，后者是异步I/O，驱动程序会在其它线程（驱动程序创建的系统线程）中完成请求。

Answer 2

   能不以异步ReadFile和同步ReadFile函数为例子来描述一下整个的执行过程呢? 谢谢了:)

Answer 3

驱动程序不应该在dispatch routine中假定自己运行于某个特定进程的context，只能说自己运行于arbitrary thread context。
你应该参考：Execution Context in NT Drivers （by osr）

Answer 4

驱动程序的分派函数总是运行在发出请求的用户线程的上下文中吗？嗯，并非如此。内核模式驱动程序设计指南4.0版的16.4.1.1小节告诉我们，“只有最高层的NT驱动程序，例如文件系统驱动程序，可以确保它们的分派函数在用户模式线程的上下文中被调用。”从我们的例子可以看出，这个说法并不完全精确。文件系统驱动程序（FSDs）当然是在发出请求的用户线程的上下文中被调用。实际上，任何因用户I/O请求而被直接调用的驱动程序，只要不是先通过另一个驱动程序，都可确保在发出请求的用户线程的上下文中被调用。这包括了文件系统驱动程序的情况。这也意味着大多数用户编写的直接为用户应用程序提供函数的标准内核模式驱动程序，例如那些过程控制设备的驱动，它们的分派函数将在发出请求的用户线程上下文中被调用。 实际上，驱动程序分派函数不在调用者线程的上下文中被调用唯一方式是用户请求首先被定向到了一个更高层的驱动程序，例如文件系统驱动程序。如果高层驱动将请求传递给了一个系统工作线程，这将导致上下文的改变。当IRP最终传递到低层驱动程序时，不能保证转发IRP的高层驱动程序运行时所处的上下文还是发出请求的用户线程的上下文。低层驱动程序将运行在任意线程上下文中。 一般的规则是，当一个设备直接被用户访问而不涉及其他驱动程序时，该设备的驱动程序的分派线程总是运行在发出请求的用户线程中。这时就有一些十分有趣的后果，使得我们能够做一些同样有趣的事情。