|
阅读：1755回复：12
StartIo & Dpc 的咄一步的
:( :( :( :( :( :( :( :( :( :( :( :(
StartIO & Dpc 都是哕\行在Dispatch_Level |
|
|
沙发#
发布于：2002-04-04 00:09
startio normally starts the IO processing, dpc normally do the actual handling after interruption.
|
|
|
|
板凳#
发布于：2002-04-04 08:36
用户被禁言,该主题自动屏蔽! |
|
|
地板#
发布于：2002-04-04 16:46
:( :( :( :( :( :( :( :( :( :(
那 |
|
|
地下室#
发布于：2002-04-04 17:13
是的
|
|
|
5楼#
发布于：2002-04-04 18:50
用户被禁言,该主题自动屏蔽! |
|
|
6楼#
发布于：2002-04-04 22:05
我也有一点不清楚：
当有一个Irp被isr转给Dpc时，startio是不是要一直等到dpc处理完毕，才启动下一个irp? |
|
|
7楼#
发布于：2002-04-06 11:18
不是，DPC可以排队。
回复 -------------- 我也有一点不清楚： 当有一个Irp被isr转给Dpc时，startio是不是要一直等到dpc处理完毕，才启动下一个irp? |
|
|
|
8楼#
发布于：2002-04-06 14:30
我认为,StartIo和DPC是两个完全不同的感念，
StartIo的任务主要是给收到的irp排队， 使驱动程序一次一个的处理收到的irp请求， 而dpc的任务是中断延时服务例程， 它的用处是为了防止处理过程较长的中断处理占用太长的时间， 使得这段时间内的新来的中断无法响应， 而把不太紧要的处理延时到以后来进行， 提高工作的效率。 这是我自己的理解，又不对的地方请大虾们指教，谢谢：） |
|
|
|
9楼#
发布于：2002-04-06 17:42
可是对硬件的操作应该是串行化的吧。
如果一个DPC正等待执行，此时又允许另一个硬件操作，那硬件的状态不就改变了？等到dpc真正执行的时候中断发生时的状态已不复存在，那怎么办？ |
|
|
10楼#
发布于：2002-04-07 10:19
如果说是DPC中断例程，应该保证在DPC处理完成前不会来下一个中断，否则可以加大外设的缓存，如果中断比你处理的要快，你死定了。但对于非实时的系统可以排队（一如文件传输）。
--------------------- 可是对硬件的操作应该是串行化的吧。 如果一个DPC正等待执行，此时又允许另一个硬件操作，那硬件的状态不就改变了？等到dpc真正执行的时候中断发生时的状态已不复存在，那怎么办？ |
|
|
|
11楼#
发布于：2002-04-07 16:17
我看chris的书里很多的地方都都用到了lockdevice
和unlockdevice程序，他们的作用就是锁定和解锁设备对象， 也就是说，为了保证硬件处理请求的串行化要求，不会破坏 执行的顺序，当每次设备对象处理某个请求的时候，就会首先查询 该设备是否已经被锁定，如果没有，就可以拥有这个设备的使用权 同时锁定此设备，防止在执行的过程中被别的请求打断。在这次请求结束的时候，在释放设备锁使其对其它请求可用。 请各位大虾指教：） |
|
|
|
12楼#
发布于：2002-04-07 20:32
不知道我这样理解对不对：
如果硬件的中断只是告诉驱动数据已经准备好并存入buffer等可以将硬件释放而数据不会丢失的情况，或者可以将硬件的状态暂存在另外分配的buf中，就可以将dpc排队，并startio下一个irp，否则就只能一次一个地执行dpc，然后再startio。 请大家指教。 |
|