There’s a member of the device’s context area that must not be written while read. The scheme is not complex, but I’m not sure how to make KMDF to automatically synchronize the accesses for me.
Here’s a summary of the possible accesses:
Device’ clean-up callback routine (W)
AddDevice callback routine (W)
EvtIoInternalDeviceControl callback routine (W)
EvtIoDeviceControl callback routine (W then R)
I believe that AddDevice and Clean-up routines cannot run simultaneously nor with to the other two routines. But how about the other two?
The other two routines ( EvtIoInternalDeviceControl & EvtIoDeviceControl) handle two different queues:
EvtIoInternalDeviceControl belongs to a parallel queue of the device (a filter).
EvtIoDeviceControl belongs to a sequential queue of a raw device which is a child of the above device.
You could use synchronization scope at device level. With that it is guaranteed that only one I/O event handler would be running at a given point of time.
Thank you for the quick reply.
Well, this is what I thought until I’ve seen that “In general, we do not recommend using device-level synchronization” in page http://msdn.microsoft.com/en-us/library/windows/hardware/ff544763(v=vs.85).aspx
My guess is that device-level synchronization makes the device work sequentially hence reducing efficiency.
In addition, note that one queue parent is the filter device while the other’s is the raw device that is a direct child of the filter device. Does it mean that the scope of “device-level synchronization” is a device and its descendants?
Mr. Zanvar is certainly correct. What he describes would work fine. BUT…
Why not just use a lock, such as a WDF Spin Lock, to protect the member in your device context? Acquire the lock before changing the value anywhere in your driver, release the lock when done.
Simple.
Sync Scope is a “big hammer” to use when all you need to do is serialize access to one member.
device level sync is per device, not across devices. You need to use your own logic to syncs access to these fields
d
debt from my phone
From: xxxxx@gmail.com
Sent: 3/10/2012 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Syncing access to device’s context area
Thank you for the quick reply.
Well, this is what I thought until I’ve seen that “In general, we do not recommend using device-level synchronization” in page http://msdn.microsoft.com/en-us/library/windows/hardware/ff544763(v=vs.85).aspx
My guess is that device-level synchronization makes the device work sequentially hence reducing efficiency.
In addition, note that one queue parent is the filter device while the other’s is the raw device that is a direct child of the filter device. Does it mean that the scope of “device-level synchronization” is a device and its descendants?
PV> Sync Scope is a “big hammer”
From the docs is seems to come free as it is embedded in the framework. I was thinking that acquiring/releasing my own lock is a considerable overhead.
DH>device level sync is per device, not across devices
Well, how about requeuing the IRP sent to the raw device into parent’s queue? Will my own logic be a better solution?
No lock is free, right? If you acquire it, or the Framework acquires it, it’s still a lock acquisition. The point, really, is how long the lock is being HELD. If you acquire it, do the work you need, and release it, then you are only serializing access to that single member that’s shared. If you use Sync Scope Device, then the ENTIRETY of all the I/O Event Processing Callbacks associated with your device will be serialized.
Sync Scope is easier to code correctly if you’re not familiar with serialization. But locking across the smallest scope possible is always going to be more efficient.
If you need to sync ACROSS devices, why not just put your own lock in your driver context, and acquire that?
Requeueing to the parent queue just for synch is a bit much. You could do it if you want. If the processing of the request in the child queue just touches the parent state and nothing in the child, then it makes more sense to fed the request to the parent
d
debt from my phone
From: xxxxx@gmail.com
Sent: 3/10/2012 8:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Syncing access to device’s context area
You replies raise new issues:
PV> Sync Scope is a “big hammer”
From the docs is seems to come free as it is embedded in the framework. I was thinking that acquiring/releasing my own lock is a considerable overhead.
DH>device level sync is per device, not across devices
Well, how about requeuing the IRP sent to the raw device into parent’s queue? Will my own logic be a better solution?