Hi,
I was examining the usages of WdfCollection in the WDF samples and have several questions regarding WdfCollection usage.
1.I noticed that it is recommended to use a lock when accessing WdfCollection. Does this mean that WdfCollection methods aren’t multi-threaded safe? (Access from more than one thread concurrently can corrupt the WdfCollection internal state?).
2.I am worried about possible deadlocks that might occur if I use the recommended form of using WdfCollection because of lock ordering issues. Suppose that I want to access a WDFDEVICE in my collection, if I access it under the collection lock, I might enter a deadlock since I my access to the WDFDEVICE is bound to acquire some locks. In the samples, the insertion to the collection is done in the EvtDriverDeviceAdd callback which is probably under another WDF lock.
Here is a simple illustration of the locking involved.
Insertion to the collection
A.EvtDriverDeviceAdd (Under WDF Lock A).
B.Collection lock is acquired (Lock B).
Checking the device in the collection
A.Collection lock is acquired (Lock B).
B.WDFDEVICE is accessed (Lock C is acquired, the relation between it and lock A is unknown).
I will appreciate if someone can shed some lights about the locks that are involved in all the scenarios mentioned above and whether a deadlock is really possible.
Thanks,
Eran.
-
the collection itself will maintain its state correctly, but it makes no such guarantees on the state of the objects in the list nor the list count itself
-
if KMDF is calling you with a lock held, it is not a publicly accessible lock nor is it a lock to maintain KMDF state (accept for very limted circumstances which are called out in the docs that a lock is held). It would be a presentation lock whose sole purpose is to guard reentrancy into your code, not to guard the state of an object.
Do not worry about locking hierarchies between your locks and KMDF locks. Worry about your own locking hierarchy and you will be OK. Deadlocks are not possible out of the box.
D
BTW EvtDriverDeviceAdd is not called with a lock held.
wrote in message news:xxxxx@ntdev…
…
> Do not worry about locking hierarchies between your locks and KMDF locks. Worry about your own locking hierarchy and you will
> be OK. Deadlocks are not possible out of the box.
Hi Doron,
Then, is there a rule in KMDF to release any driver locks before calling
a framework API, like in NDIS?
The example that Eran gives, is similar to deadlocks I’m untangling for
the last few days (however, KMFD is not involved there).
The framework itself calls me while holding some lock (A) on my miniport,
and then I take my own lock (B).
In another thread, I take lock B and call into the framework, that grabs lock A in the way.
( the NDIS folks warned against this, and rats! they were right )
Again, that framework is not KMDF, but why KMDF should behave differently.
Regards,
–PA
For the most part this should be able to happen (*) . The locks that
KMF takes before calling into your driver have ownership built into
them, so we know to back off the lock if it is already held. For
instance, the potential locks that the WDFQUEUE will acquire behave this
way. This can happen if you violate the documented restrictions; the
comparison/copy callbacks for WDFCHILDLIST have such restrictions or if
you call WdfDeviceStopIdle(TRUE) while you are in a power up callback
(which deadlocks not b/c of a locking hierarchy violation, but rather
blocking to wait for something to happen while in the path of thing you
are waiting on).
OTOH, many APIs are like IoCompleteRequest, you should not be holding
onto a lock while making that call.
KMDF does not release locks that the driver acquired.
d
(*) we are obviously not perfect so there could be scenarios where we
didn’t account for correctly acquiring the lock and we do deadlock.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, November 24, 2006 3:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfCollection and deadlocks
wrote in message news:xxxxx@ntdev…
…
> Do not worry about locking hierarchies between your locks and KMDF
locks. Worry about your own locking hierarchy and you will
> be OK. Deadlocks are not possible out of the box.
Hi Doron,
Then, is there a rule in KMDF to release any driver locks before calling
a framework API, like in NDIS?
The example that Eran gives, is similar to deadlocks I’m untangling for
the last few days (however, KMFD is not involved there).
The framework itself calls me while holding some lock (A) on my
miniport,
and then I take my own lock (B).
In another thread, I take lock B and call into the framework, that grabs
lock A in the way.
( the NDIS folks warned against this, and rats! they were right )
Again, that framework is not KMDF, but why KMDF should behave
differently.
Regards,
–PA
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer