IRP队列问题：为什么非要完成先排队的IRP，才能完成后发的其他不排队IRP请求？

用DriverWork开发驱动，在驱动中继承KDriverManagedQueueEx类实现了一个IRP队列，目的是排队IRP_MJ_READ请求，但在驱动实际运行中发现，排队IRP_MJ_READ请求后，我再发其他IRP请求，比如IRP_MJ_DEVICE_CONTROL请求，驱动将不能处理，只有完成先排队的IRP_MJ_READ请求，才能处理。

   如果是这样的话，是不是说IRP是必须顺序完成的？能不能不顺序完成IRP？

补充一句，只排队IRP_MJ_READ请求，其他IRP不排队

没有人硬性要求。只是大多数设备都是串行处理数据

我知道设备是串行处理数据，但我想实现的是

* 先排队某个IRP请求
* 设备再处理其他的IRP请求
* 完成排队的IRP请求

这种IRP处理方式能实现吗？

顶一下，等大虾来解惑

* 先排队某个IRP请求
* 设备再处理其他的IRP请求
* 完成排队的IRP请求
.......[/quote]


这段时间一直在研究IRP，也来涂鸦几句。
上面的思想可以实现的，而且内核和驱动中也是这样处理的，
比如说你设备接收休眠IRP状态信息的时候，并且正在处理的时候，系统又接收到唤醒状态IRP
系统会自动给IRP排队，等待完成一个请求再从IRP请求队列栈中取下一个请求，这样的目的很明显哈
另外同意设备一段时间内只处理一个同一状态的IRP，其他的用直接完成例程over了，具体实现你可一
看下代码，强烈建议看 windows开源部分的内核源代码

以上个人意见，欢迎大牛们指正，呵呵

我不想系统自动排队，我想自己创建一个自己的IRP队列，如一楼所言，但结果是排队某个IRP请求后，设备就不能处理其他IRP请求了，很奇怪，我并没有用设备的IRP队列，用的是KDriverManagedQueueEx这个类实现的，不应该出现这种情况啊

引用第6楼fimp1于2007-04-30 11:59发表的“”:
我不想系统自动排队，我想自己创建一个自己的IRP队列，如一楼所言，但结果是排队某个IRP请求后，设备就不能处理其他IRP请求了，很奇怪，我并没有用设备的IRP队列，用的是KDriverManagedQueueEx这个类实现的，不应该出现这种情况啊

你怎么实现排队的？现象是什么？

大致实现步骤是这样
* 在驱动中继承KDriverManagedQueueEx类实现了一个IRP队列类MyDriverManagedQueue
* 在设备类里声明一个成员变量MyDriverManagedQueue m_DriverManagedQueue;
* 在设备类的IRP_MJ_READ处理函数排队IRP_MJ_READ请求，IRP_MJ_READ处理函数如下
NTSTATUS iSKeyLogDrvDevice::Read(KIrp I)
{
    T.Trace(TraceInfo, __FUNCTION__"++.  IRP %p\n", I);

    NTSTATUS status = STATUS_SUCCESS;

    // 排队IRP不完成IRP
    status = m_DriverManagedQueue.QueueIrp(I);

    T.Trace(TraceInfo, __FUNCTION__"--.  IRP %p, STATUS %x\n", I, status);

    return status;
}

然后就出现我说的情况，只要我排队了IRP_MJ_READ请求，再向设备发IRP_MJ_DEVICE_CONTROL请求，设备都不会处理后发的IRP_MJ_DEVICE_CONTROL请求，只有完成排队的IRP_MJ_READ请求后，设备才会处理后发的IRP_MJ_DEVICE_CONTROL请求

引用第8楼fimp1于2007-04-30 15:16发表的“”:
大致实现步骤是这样
* 在驱动中继承KDriverManagedQueueEx类实现了一个IRP队列类MyDriverManagedQueue
* 在设备类里声明一个成员变量MyDriverManagedQueue m_DriverManagedQueue;
* 在设备类的IRP_MJ_READ处理函数排队IRP_MJ_READ请求，IRP_MJ_READ处理函数如下
NTSTATUS iSKeyLogDrvDevice::Read(KIrp I)
{
   T.Trace(TraceInfo, __FUNCTION__"++. IRP %p\n", I);

   NTSTATUS status = STATUS_SUCCESS;

   // 排队IRP不完成IRP
   status = m_DriverManagedQueue.QueueIrp(I);

   T.Trace(TraceInfo, __FUNCTION__"--. IRP %p, STATUS %x\n", I, status);

   return status;
}

然后就出现我说的情况，只要我排队了IRP_MJ_READ请求，再向设备发IRP_MJ_DEVICE_CONTROL请求，设备都不会处理后发的IRP_MJ_DEVICE_CONTROL请求，只有完成排队的IRP_MJ_READ请求后，设备才会处理后发的IRP_MJ_DEVICE_CONTROL请求

说了半天，你所谓的设备是指你的driver吧？

那所谓的不处理是什么意思？没有进入DeviceIoControl Dispatcher？还是QueueIrp函数阻塞？

对，设备是指的driver，情况是没进入DeviceIoControl Dispatcher，QueueIrp函数没有阻塞

你用CreateFile打开设备的是用OVERLAPPED方式吗？如果不是试试OVERLAPPED，如果是...

我没有用OVERLAPPED方式打开设备，使用同步方式打开的，这是这个问题的根本原因吗，也就是说要用IRP队列就需要用异步方式打开设备才行吗？

咦？回的贴怎么都不见了？只有再问一次了

不处理是指：没有进入DeviceIoControl Dispatcher

QueueIrp函数没有阻塞，处理完排队的IRP_MJ_READ请求，才会进入DeviceIoControl Dispatcher处理其他IRP请求

引用第12楼fimp1于2007-04-30 16:41发表的  :
我没有用OVERLAPPED方式打开设备，使用同步方式打开的，这是这个问题的根本原因吗，也就是说要用IRP队列就需要用异步方式打开设备才行吗？

使用同步貌似没有传说中的系统IRP队列吧,,,

只有设备响应慢的才有必要用异步,这时候排队才有意义,,,
这个队列由系统缺省维护或自定义都可以,至于先来先服务，还是其他服务算法貌似不应该是固化的,也就是自己可以修改或自定义之类。..

我只会吹吹水