My driver has a resource that I want to protect across a few function calls, which might not all be in the same thread.
I plan to use a synchronization Event.
A driver dispatch routine will wait on the Event. It usually queues a DPC, which in some cases will request an IoWorkItem. Whichever of these three was the last to run will set the Event, which then allows another dispatch routine to use the resource.
Are there any gotchas associated with this? I saw something somewhere about kernel dispatcher objects being used in an arbitrary thread context. I believe this applies to a wait (since the wait involves knowing about which thread is waiting), but not to any SetEvent call (with wait = false).
I also have a "service" DPC which gets queued from time to time. This will do some work on the protected resource. All DPCs on the same resource are targeted to the same CPU, so that takes care of preventing it from running concurrently with the "dispatch" DPC. The service DPC is queued in response to a timer event, or possibly from a hardware interrupt.
There are occasions where the dispatch DPC puts the resource in a "disabled" state where I don't want any service DPC to run any more. It would call KeRemoveQueueDpc, but if it returns FALSE, is it possible that the service DPC is still waiting on the CPU's DPC queue?
I assume that this is possible if the timer or interrupt event occurred while the dispatch DPC was running but before the KeRemoveQueueDpc call. So how to I synchronize this?
I gather that I would need a second "service completed" dispatcher object of some sort. It would have to be in the unsignaled state if the dispatch DPC disabled the resource and the service DPC was queued and KeRemoveQueueDpc returned FALSE and the service DPC has not yet run.
Does this sound like a good strategy, or is there a simpler solutiion?
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Writing WDF Drivers||25 Feb 2019||OSR Seminar Space|
|Developing Minifilters||8 April 2019||OSR Seminar Space|