In my driver I want to serialize all IoRead and IoWrite requests and additionally
all file FileCreate and FileClose events.
I learned that IoCreate and IoClose events are not sent to the default queue
so I tried to create a (non default) I/O queue with callbacks for
EvtIoRead, EvtIoWrite and EvtIoDefault but I do not get a callback
for EvtDeviceFileClose but only EvtDeviceFileCreate!
What is the proper way to achieve this kind of serialization?
Do I have to provide my own lock to prevent any of these callbacks to
be running concurrently or can I configure the framework to serialize
these callbacks for me?
If your application opens the device without FILE_FLAG_OVERLAPPED, all requests will be serialized. If the device will be declared Exclusive, only one FILE_OBJECT will be allowed to open on it at any time.
Hello Alex,
thanks for the answer. Unfortunately this is not my use case.
My device (driver) will be opened from several processes
and threads at the same time.
What problem are you solving by trying to synchronize cleanup and close across multiple file objects. Evtfileclose (and cleanup) is a synchronous operation which is why you can’t get them via a queue. Sounds like you have device wide synch already, just grab the object lock of your wdfdevice in Evtfileclose to synchronize with the rest
d
debt from my phone
From: xxxxx@frank-wolf.org
Sent: 9/17/2012 7:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Proper serialization of file IoRead /Write+FileCreate/Close
Hello Alex,
thanks for the answer. Unfortunately this is not my use case.
My device (driver) will be opened from several processes
and threads at the same time.
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
Hello Doron,
right now I’m still in the phase of experimenting and learning. My task is to write some
kind of multiple reader/writer queue. Similar to a IPC (via shared memory) that can be
used via “normal” File API instead of shared memory.
(There’s also some H/W to control etc. but in the end it comes down to the use case
above.)