none
Using Device dedicated threads RRS feed

  • Question

  • Hi All,

    The points from "Introduction to Kernel Dispatcher Objects" are below, i couldn't understand:

    --The dispatch routines of lower-level drivers cannot wait for a dispatcher object for the completion of asynchronous I/O operations.

    What is the problem if we wait for async i/o opeations?

    --As a general guideline, if you expect that your new device driver will often need to stall for longer than 50 microseconds while it waits for device-state changes during I/O operations, consider implementing a driver with a device-dedicated thread

    What dose the above statement mean?

    Please clarify.



    • Edited by Boomi.s Sunday, March 15, 2015 6:41 PM
    Sunday, March 15, 2015 6:31 PM

Answers

  • In general you should not wait on a dispatcher object in a driver dispatch routine.  Think about it, the request to be processed by driver dispatch routine comes in as asynchronous, therefore someone above the driver, is expecting to be able to do work while the request is processed, if you block the thread by waiting on a dispatcher object you violate this assumption.

    The second statement is that if you need to wait a lot for I/O to complete, consider doing this in its own thread, so that the calling thread is not blocked.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Sunday, March 15, 2015 6:52 PM

All replies

  • In general you should not wait on a dispatcher object in a driver dispatch routine.  Think about it, the request to be processed by driver dispatch routine comes in as asynchronous, therefore someone above the driver, is expecting to be able to do work while the request is processed, if you block the thread by waiting on a dispatcher object you violate this assumption.

    The second statement is that if you need to wait a lot for I/O to complete, consider doing this in its own thread, so that the calling thread is not blocked.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Sunday, March 15, 2015 6:52 PM
  • Thanks Don.
    • Edited by Boomi.s Sunday, March 15, 2015 8:57 PM
    Sunday, March 15, 2015 8:12 PM
  • I have one more question:

    --Any standard driver routine that runs at IRQL = DISPATCH_LEVEL cannot wait for a nonzero interval on any dispatcher objects without bringing down the system. However, such a routine can call KeSetEvent while running at an IRQL less than or equal to DISPATCH_LEVEL.

    Why can't we wait on dispatcher objects for sometime (20MicroSeconds) at DISPATCH_LEVEL?

    Sunday, March 15, 2015 9:04 PM
  • DISPATCH_LEVEL disables scheduling, waiting on a dispatcher object requires scheduling.  So you can use KeWaitForSingleObject with Timeout=0 since it will not wait, but you cannot use it with any other value because it will.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Sunday, March 15, 2015 9:09 PM
  • Hi Don, I have question from the below paragraph:

    --A pageable thread or pageable driver routine that runs at IRQL < DISPATCH_LEVEL should never
    call KeSetEvent with the Wait parameter set to TRUE. Such a call causes a fatal page fault
    if the caller happens to be paged out between the calls to KeSetEvent and
    KeWaitForSingleObject or KeWaitForMultipleObjects.

    My question is:

    From the above paragraph, when i use the KeSetEvent in my pageable thread at PASSIVE_LEVEL, the IRQL value will be raised to some high level (SYNCH_LEVEL). When my thread IRQL is increased to HIGH_LEVEL, dispatcher can't run. Then how my thread will be paged out?

    Sunday, March 15, 2015 10:09 PM
  • KeSetEvent with a Wait parameter set to TRUE exits the call with the scheduling lock held and the IRQL = DISPATCH_LEVEL, since the next call will be a KeWaitForXXXObject call, so it is an optimization that does not require releasing then taking the lock.  The problem here is if your code is pageable, the call to KeWaitXXX can be paged out, and you cannot page in code at DISPATCH_LEVEL.

    These calls do not raise the code to SYNCH_LEVEL or HIGH_LEVEL.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Sunday, March 15, 2015 10:19 PM
  • So even if the code is in DISPATCH_LEVEL(IRQL) after KeSetEvent(), it can be paged out?

    Who does the page out/page in code? Is it Scheduler? Because Dispatcher can't run once my code is in DISPATCH_LEVEL.

    Monday, March 16, 2015 2:44 AM
  • Is my question is wrong? Or something i misunderstood.
    • Edited by Boomi.s Monday, March 16, 2015 10:41 PM
    Monday, March 16, 2015 10:40 PM
  • It can be paged out before you return from KeSetEvent, at which point it could not be paged in.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Monday, March 16, 2015 11:22 PM
  • Hi Don,

    I am not able to conclude. Help me to clarify this:

    When my thread invokes the KeSetEvent(), inside that function IRQL will be raised to DISPATCH_LEVEL. So my thread will be running at DISPATCH_LEVEL before KeSetEvent() returns.

    So who does the page out operation/what IRQL it is running?

    Tuesday, March 17, 2015 5:14 AM
  • Think of these actions:

    Thread calls KeSetEvent()

    System pages out code with call to KeSetEvent()

    Thread attempts to return from KeSetEvent() at DISPATCH_LEVEL

    System crashes since it can't page in the location to return to


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Tuesday, March 17, 2015 11:17 AM