Are WDFQUEUEs thread-safe?

NTDEV
1

Hi all,

while investigating an otherwise unrelated bug, I’ve noticed some
strange code that I must have written a few years ago: In a WDF driver’s
EvtIoInternalDeviceControl routine (WdfSynchronizationScopeDevice was
specified) I call WdfRequestForwardToIoQueue(), and in a background
thread I call WdfIoQueueRetrieveNextRequest() to process the requests.

Now shouldn’t this background thread be using some kind of explicit
synchronization mechanism (such as calling WdfObjectAcquireLock(device))
before accessing the queue? Right now it doesn’t, and this looks like a
recipe for disaster. Apparently it isn’t (I’ve never experienced crashes
that looked like queue corruption), but I don’t know why. I scanned the
WDK docs for an explanation (such as “Forward/Retrieve are atomic
operations”), but I didn’t find one.

So have I just been lucky so far and should fix my code ASAP? Or do the
WDFQUEUE access routines already contain some implicit synchronization,
and I’m just too stupid to find the spec that says so?

2

ALL of the WDF functions are internally protected by appropriate locks. So, for example, you don’t need to worry about calling WdfRequestForwardToIoQueue() in two separate threads… KMDF takes care of this for you. It would be a pretty terrible framework if it didn’t.

Now, obviously, the functions aren’t EXTERNALLY protected. Thus, if you enumerate a collection (for example) and find an entry and then remove it, you are responsible for providing the locking prior to the start of the enumeration through the removal operation.

Hope that helps,

Peter
OSR

3

So in your case, WdfIoQueueRetrieveNextRequest will race with the forward and may miss the request you just inserted…all the while, as Peter said, the queue will maintain proper state

d

debt from my phone

From: xxxxx@osr.com
Sent: 8/20/2012 6:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Are WDFQUEUEs thread-safe?

ALL of the WDF functions are internally protected by appropriate locks. So, for example, you don’t need to worry about calling WdfRequestForwardToIoQueue() in two separate threads… KMDF takes care of this for you. It would be a pretty terrible framework if it didn’t.

Now, obviously, the functions aren’t EXTERNALLY protected. Thus, if you enumerate a collection (for example) and find an entry and then remove it, you are responsible for providing the locking prior to the start of the enumeration through the removal operation.

Hope that helps,

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

4

PeterGV wrote:

ALL of the WDF functions are internally protected by appropriate
> locks. So, for example, you don’t need to worry about calling
> WdfRequestForwardToIoQueue() in two separate threads… KMDF takes
> care of this for you. It would be a pretty terrible framework if it
> didn’t.
>
> Hope that helps,

Thanks, it does.

I’m still kind of confused why I can’t find an equivalent statement in
the “Framework Queue Objects” or “Synchronization Techniques” chapter of
the KMDF design guide, and not in the Orwick/Smith book, either.

But maybe the authors just found it too obvious that no one would write
a framework with queues that are harder to use than queues built upon
the ExInterlockedXxxList functions. :slight_smile:

5

We thought it would be obvious. Feel free to file a comment on the doc page and ask for clarification

d

debt from my phone

From: Wilhelm N?ker
Sent: 8/20/2012 8:18 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Are WDFQUEUEs thread-safe?

PeterGV wrote:

ALL of the WDF functions are internally protected by appropriate
> locks. So, for example, you don’t need to worry about calling
> WdfRequestForwardToIoQueue() in two separate threads… KMDF takes
> care of this for you. It would be a pretty terrible framework if it
> didn’t.
>
> Hope that helps,

Thanks, it does.

I’m still kind of confused why I can’t find an equivalent statement in
the “Framework Queue Objects” or “Synchronization Techniques” chapter of
the KMDF design guide, and not in the Orwick/Smith book, either.

But maybe the authors just found it too obvious that no one would write
a framework with queues that are harder to use than queues built upon
the ExInterlockedXxxList functions. :slight_smile:

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

6

It is a fundamental error to confuse “structural integrity” with concepts
like “informational integrity”. For example, if you don’t use a
transaction on a multi-table database, each table is structurally correct,
but the information between tables is inconsistent. I find this is the
most frequent errors my students made when dealing with multithreaded
user-level code.
joe

So in your case, WdfIoQueueRetrieveNextRequest will race with the forward
and may miss the request you just inserted…all the while, as Peter said,
the queue will maintain proper state

d

debt from my phone

From: xxxxx@osr.com
Sent: 8/20/2012 6:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Are WDFQUEUEs thread-safe?

ALL of the WDF functions are internally protected by appropriate locks.
So, for example, you don’t need to worry about calling
WdfRequestForwardToIoQueue() in two separate threads… KMDF takes care of
this for you. It would be a pretty terrible framework if it didn’t.

Now, obviously, the functions aren’t EXTERNALLY protected. Thus, if you
enumerate a collection (for example) and find an entry and then remove it,
you are responsible for providing the locking prior to the start of the
enumeration through the removal operation.

Hope that helps,

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

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