Hi all
I’m reading the WDK document and found some guideline in it, some
rules I can understand the reason but some can not, for example
"
no driver queues any operations while handling the I/O request, and no
driver returns until the driver below it has finished handling the request.
A driver must not attempt to wait for a dispatcher object to be set to the
Signaled state for the completion of a transfer operation to or from a
paging device.
"
why can’t we wait dispatcher object in these situation?
and in the describe of mutex and semaphore, it says that mutex can avoid
deadlock in SMP machines but semaphore can not. How can deadlock happens if
we only acquire one lock? And if there are two or more locks, why mutex can
avoid this without the careful design of coder but semaphore can not?
I think WDK document only tells us what we can do and what we can not do,
but never tells the reason, so if I want to know the reason, where is the
right place I can go?
thanks
Let me start by saying that this section of the WDK documentation isn’t particularly well-written and probably causes more problems than it solves as a result. The problem is that the writer here was obviously trying to provide some general guidelines and then simplify them by providing specific guidance that a driver developer can use without having to understand the subtleties of Windows OS architecture. That’s a hard problem, and it’s only handled here with limited success.
The general guidance is correct: You can only block if you’re running in a non-arbitrary thread context and at less than IRQL DISPATCH_LEVEL. I’m not sure that I understand the allowance for “completely synchronous I/O”… and, in fact, I’m not sure how any driver would know what I/O requests are guaranteed to be “completely synchronous” (which is a term that’s invented in this section, by the way, not a standard Windows architectural concept I’ve ever heard of).
There are a lot of little bitty issues on this page…
In terms of your specific questions, the first sentence above,
is merely the attempted definition of “a completely synchronous I/O request” in the previous sentence… and the section says you CAN wait on a dispatcher object in this case. As I said before, I’m not sure I understand what the writer is getting at here, but, that at least explains the sentence you asked above.
You also asked about:
THAT one I can answer: This is to avoid a deadlock on page fault.
They try to provide a BALANCE. Back in the old days, the documentation was often criticized because it ONLY provided architectural descriptions… but rarely provided practical guidance. For the last (many, 10+) years the doc writers have tried to make the documentation more useful from a practical standpoint, and to describe the path that driver writers should stay on to avoid problems. This has, in general, been quite successful. But there are exceptions.
Peter
OSR
Thanks for your reply
2011/1/25
> Let me start by saying that this section of the WDK documentation isn’t
> particularly well-written and probably causes more problems than it solves
> as a result. The problem is that the writer here was obviously trying to
> provide some general guidelines and then simplify them by providing specific
> guidance that a driver developer can use without having to understand the
> subtleties of Windows OS architecture. That’s a hard problem, and it’s only
> handled here with limited success.
>
> The general guidance is correct: You can only block if you’re running in a
> non-arbitrary thread context and at less than IRQL DISPATCH_LEVEL. I’m not
> sure that I understand the allowance for “completely synchronous I/O”…
> and, in fact, I’m not sure how any driver would know what I/O requests are
> guaranteed to be “completely synchronous” (which is a term that’s invented
> in this section, by the way, not a standard Windows architectural concept
> I’ve ever heard of).
>
> There are a lot of little bitty issues on this page…
>
> In terms of your specific questions, the first sentence above,
>
>
>
> is merely the attempted definition of “a completely synchronous I/O
> request” in the previous sentence… and the section says you CAN wait on a
> dispatcher object in this case. As I said before, I’m not sure I understand
> what the writer is getting at here, but, that at least explains the sentence
> you asked above.
>
> You also asked about:
>
>
>
> THAT one I can answer: This is to avoid a deadlock on page fault.
>
I’m a little confused about “completion of a transfer”, if this completion
means:
dispatch routine
IoCallDriver…
KeWaitForSingleObject…
----
CompleteRoutine:
KeSetEvent
I think this is a normal way to perform synchronous IO
and if it meas:
CompleteRoutine:
KeWaitForSingleObject
That make sense, but I still can’t understand why…
>
>
>
> They try to provide a BALANCE. Back in the old days, the documentation was
> often criticized because it ONLY provided architectural descriptions… but
> rarely provided practical guidance. For the last (many, 10+) years the doc
> writers have tried to make the documentation more useful from a practical
> standpoint, and to describe the path that driver writers should stay on to
> avoid problems. This has, in general, been quite successful. But there are
> exceptions.
>
Totally understand.
I have several book about windows kernel and driver develop, none of them
describe these details, maybe I have to ask some experts every time I got a
problem…
>
> Peter
> OSR
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Do you have Windows Internals? The book does an accurate job at describing the IRQL rules and how dispatcher objects are treated as well as the various restrictions.
–
Best regards,
Alex Ionescu
Though perhaps more to do with your example than your original question, one generally cannot use dispatcher objects in completion routines… because completion routines can be called at <= IRQL DISPATCH_LEVEL.
Peter
OSR