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