Device Locking/Sequential Queue

Hi,

Using device locking and a sequential queue, if a read request (A) arrives
from the application and the driver forwards that to a manual queue and
sends a new request (A’) in its place down to the device, is it possible
for a subsequent application read request (B) to be delivered prior to
A’ and the original A request completing?

http://msdn.microsoft.com/en-us/library/windows/hardware/ff554538(v=vs.85).aspx

[quote] The queue defers any additional requests until the driver finishes
processing its current request or calls the IWDFIoRequest::ForwardToIoQueue
method to requeue the request.[/quote]

suggests that to be the case, or have I misinterpreted it?

Assuming I’ve read the above correctly, another thread on here mentioned that the
completion order for requests is not guaranteed. So it’s
possible B’ callback might occur prior to A’

If that’s the case, I wouldn’t want to complete the original B request
until A at the head of the manual queue has completed. Would the
appropriate way to handle this be to tie some context information to the
A’,B’ requests so that when for example B’ completes, the context information
can be used to access and copy the data into B whilst leaving B on the
manual queue until A’ and in turn, the current head A completes?

Finally, with device level locking, the docs mention OnCompletion is not part
of the automatic locking. Does/Can the framework call OnCompletion from multiple
threads such that the callback for A’ and B’ can end up interleaved?

Regards,

Gary

Device level locking will help you with the coordination of your callbacks, but will not do anything to order IO operations as they come in.

Once you forward A to the manual queue, the sequential queue is idle and WDF is free to present B to you. However with device level locking the callback to present B will block waiting for the callback that presented A (or any other callbacks which might be active within that locking scope). It will not stop the presentation, nor will it make the presentation dependent on the completion of A.

If you don’t want B to come in until A completes, why forward A to a manual queue at all? Just leave it pending on the sequential queue, allocate a new request (A’), send A’ to the lower device, and when A’ completes you can complete A. Or just format A and send it to the IO target (this does not clear the queue).

Otherwise you have a manual queue of pending requests. You’d need to keep some context between B’ and B, so that when B’ completes you can (a) check the first request in the queue (b) complete the first request if it’s B or mark B as complete if the first request isn’t B and (c) if you completed a request, check the next request and see if it’s complete.

-p

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@figmentgames.com
Sent: Thursday, January 8, 2015 1:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Locking/Sequential Queue

Hi,

Using device locking and a sequential queue, if a read request (A) arrives from the application and the driver forwards that to a manual queue and sends a new request (A’) in its place down to the device, is it possible for a subsequent application read request (B) to be delivered prior to A’ and the original A request completing?

http://msdn.microsoft.com/en-us/library/windows/hardware/ff554538(v=vs.85).aspx

suggests that to be the case, or have I misinterpreted it?

Assuming I’ve read the above correctly, another thread on here mentioned that the completion order for requests is not guaranteed. So it’s possible B’ callback might occur prior to A’

If that’s the case, I wouldn’t want to complete the original B request until A at the head of the manual queue has completed. Would the appropriate way to handle this be to tie some context information to the A’,B’ requests so that when for example B’ completes, the context information can be used to access and copy the data into B whilst leaving B on the manual queue until A’ and in turn, the current head A completes?

Finally, with device level locking, the docs mention OnCompletion is not part of the automatic locking. Does/Can the framework call OnCompletion from multiple threads such that the callback for A’ and B’ can end up interleaved?

Regards,

Gary


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Hi Peter,

If you don’t want B to come in until A completes, why forward A to a manual queue at all?

That hadn’t occurred to me but now you mention it, that would simplify matters.

Otherwise you have a manual queue of pending requests. You’d need to keep some
context between B’ and B, so that when B’ completes you can (a) check the first request
in the queue (b) complete the first request if it’s B or mark B as complete if the first
request isn’t B and (c) if you completed a request, check the next request and see if it’s
complete.

Yes that’s exactly what I was planning to do, although leaving A on the original queue
as you mentioned will simplify matters so I may be able to avoid this now.

If I did continue with a manual queue however, from what I can gather the other callbacks
I use have the locking handled by the framework under device level locking, but not the
OnCompletion? So unless I add any additional locking such as a critical section, the
callback for one completion could be pre-empted and interleaved with another completion?

Thanks,

Gary

You can lock the device to enter the device locking scope from your completion routines.

Sent from my Windows Phone


From: xxxxx@figmentgames.commailto:xxxxx
Sent: ?1/?9/?2015 4:30 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Device Locking/Sequential Queue

Hi Peter,

>If you don’t want B to come in until A completes, why forward A to a manual queue at all?

That hadn’t occurred to me but now you mention it, that would simplify matters.

> Otherwise you have a manual queue of pending requests. You’d need to keep some
> context between B’ and B, so that when B’ completes you can (a) check the first request
> in the queue (b) complete the first request if it’s B or mark B as complete if the first
> request isn’t B and (c) if you completed a request, check the next request and see if it’s
> complete.

Yes that’s exactly what I was planning to do, although leaving A on the original queue
as you mentioned will simplify matters so I may be able to avoid this now.

If I did continue with a manual queue however, from what I can gather the other callbacks
I use have the locking handled by the framework under device level locking, but not the
OnCompletion? So unless I add any additional locking such as a critical section, the
callback for one completion could be pre-empted and interleaved with another completion?

Thanks,

Gary


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>