File Object Lock with WDK
in [Device Drivers]
|
Prev: American E-commerce Increasingly Outside the Legal Positions
Next: How to get device key (hardware key) path in kernel mode ?
From: Asaf Shelly on 19 Aug 2010 16:13 Hi Pavel, I am forwarding the request to the COM port and unless overlapped IO is used the thread is suspended until a character is input and the driver remains locked until the request was completed. I can tell the user to use overlapped IO but I don't want application to stop responsing if someone will not in the fufute. Thanks, Asaf "Pavel A." wrote: > If you open \\?\MyDevice\COM1 and \\?\MyDevice\COM2, > you get handles to different file objects, so synchronous requests > to these run independently. > > However, the blocking on sync handles occurs in user mode. > Drivers always complete requests and get out quickly, maybe > with STATUS_PENDING. > Windows is not Unix. > > --pa > > > "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > news:50F8C3CA-EF1C-4AE0-81DE-0D56F9ACD884(a)microsoft.com... > > Hi Doron, > > > > Thanks! This is exactly what I needed. Can you please go over the > > documentation and verify that this information is there? I spent a while > > searching for samples or this explanation but could not find any. Keep in > > mind that it is hard to search for this issue in a search engine. There > > are > > so many search results for "File", "Driver", "Object", "Lock", "Queue" > > which > > are not related to a Driver's File Object based Lock. > > > > Thanks again, > > Asaf > > > > > > "Doron Holan [MSFT]" wrote: > > > >> you can create your own set of queues per WDFFILEOBJECT. specify the > >> WDFFILEOBJECT as the parent when you create the queues in > >> EvtDeviceFileCreate. from your top level dispatching queue, you find the > >> WDFFILEOBJECT specific queue and forward the request to that queue. you > >> can > >> then use queue level synchronization and each file object is separate > >> from > >> each other. > >> > >> d > >> > >> "Asaf Shelly" wrote in message > >> news:EEF1F838-3A0A-4788-816C-DECC903FC106(a)microsoft.com... > >> > >> Hi Abhishek, > >> > >> I have a driver which is a higher level to the COM port, so it is using a > >> Serial Port as the lower driver. > >> My application opens my driver for communication and the driver can > >> either > >> read, write, send periodic buffers, and manipulate data. Currently I need > >> an > >> instance of the driver for every COM port so basically if I have 5 COM > >> ports > >> on the machine then I also need 5 instances of my virtual device. > >> What I would like to do is open my device with the COM number so instead > >> of > >> using \\?\MyDevice1 for COM1 and \\?\MyDevice2 for COM2, I would like to > >> use > >> \\?\MyDevice\COM1 and \\?\MyDevice\COM2. > >> This is working, except that if my device is forwading a request in > >> transparent mode then it is possible that the lower level driver will > >> block > >> to completion and my driver cannot handle any other request till > >> completion. > >> I can solve this in many ways but am looking for a clean design with KMDF > >> support. > >> > >> From what I have seen there is some support for FOs in KMDF but fewer > >> samples than any other solution. Is FO support limited in this version of > >> KMDF? > >> > >> Thanks for the fast response. > >> > >> Regards, > >> Asaf > >> > >> > >> "Abhishek Ram [MSFT]" wrote: > >> > >> > Can you provide a little more information on what you are trying to > >> > accomplish? Which callbacks do you need to synchronize based on file > >> > object? > >> > > >> > "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > >> > news:4578B801-0376-498D-8046-2B6DE6AE9122(a)microsoft.com... > >> > > Hi Pavel and Abhishek, > >> > > > >> > > Thanks for the answers. So basically if I need File-Object based > >> > > synchronization then I should not use Queue based synchronization and > >> > > instead > >> > > do this manually, correct? > >> > > > >> > > Is there any lock object attached to the File Object? > >> > > > >> > > TIA, > >> > > Asaf > >> > > > >> > > > >> > > "Pavel A." wrote: > >> > > > >> > >> "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > >> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C(a)microsoft.com... > >> > >> > Hi All, > >> > >> > > >> > >> > I know that it is possible to have an automatic synchronization > >> > >> > that > >> > >> > is > >> > >> > based on File Object: > >> > >> > http://msdn.microsoft.com/en-us/library/ff544763(VS.85).aspx > >> > >> > > >> > >> > Can't find anywhere that says how. > >> > >> > > >> > >> > TIA, > >> > >> > Asaf > >> > >> > >> > >> Automatic synchronization is not _based_ on file objects. > >> > >> Rather, callbacks of a file object, that belongs to certain device > >> > >> object, > >> > >> can be synchronized with other callbacks of that file object, and > >> > >> with > >> > >> other callbacks of that device object. > >> > >> This is implemented by taking a lock in the device object. > >> > >> > >> > >> Call WdfDeviceInitSetFileObjectConfig > >> > >> with WDF_OBJECT_ATTRIBUTES where you specify SynchronizationScope > >> > >> and ExecutionLevel as needed. > >> > >> > >> > >> -- pa > >> > >> > >
From: Asaf Shelly on 19 Aug 2010 16:57 I need driver-wide synchronization to protect FO creation and cleanup. On the other hand I don't want an application using ReadFile on a COM port to block the entire driver from working. At least block only the application that did the read, not all the applications using the device. My real scenario is that I am keeping an internal read queue and the application reads periodically all the collected data (I know that there is always data to read). Generally speaking I can see a scenario where the application is creating a file and using a reader thread and a writer thread on the same file handle. I would want to protect driver wide resources but allow parallel reads and writes. What is the implementation for this? consider old school fopen("COM1") Asaf "Maxim S. Shatskih" wrote: > > My test application does not use FILE_FLAG_OVERLAPPED because my user is not > > used to it. > > The device might receive other requests, mainly Create File / Close Handle / > > Cleanup, and power, so basically I do need device level synchronization as > > well. > > Currently the synchronization scope is Queue level, but this without doron's > > solution is only device wide lock. > > So what? You need delice-level synchronization, and the KMDF queue gives you this. All is OK. > > And, if you need file-level synchronization, then just never use FILE_FLAG_OVERLAPPED, and all IRPs sent to this file object will be serialized by IO. > > -- > Maxim S. Shatskih > Windows DDK MVP > maxim(a)storagecraft.com > http://www.storagecraft.com > > . >
From: Maxim S. Shatskih on 19 Aug 2010 17:03 > On the other hand I don't want an application using ReadFile on a COM port > to block the entire driver from working Sorry, but COM ports usually support only 1 file object created, the second create will fail. This is done with Exclusive flag in IoCreateDevice. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Abhishek Ram [MSFT] on 19 Aug 2010 18:01 > Generally speaking I can see a scenario where the application is creating > a > file and using a reader thread and a writer thread on the same file > handle. I > would want to protect driver wide resources but allow parallel reads and > writes. What is the implementation for this? consider old school > fopen("COM1") If your application wants to have parallel reads and writes on the same file handle, it needs to specify FILE_FLAG_OVERLAPPED. Please see the documentation for CreateFile, specifically the documentation of this flag: "If this flag is specified, the file can be used for simultaneous read and write operations. If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:4C9B7831-31E7-4C72-9054-AC23253F375E(a)microsoft.com... > I need driver-wide synchronization to protect FO creation and cleanup. > On the other hand I don't want an application using ReadFile on a COM port > to block the entire driver from working. At least block only the > application > that did the read, not all the applications using the device. > > My real scenario is that I am keeping an internal read queue and the > application reads periodically all the collected data (I know that there > is > always data to read). > > Generally speaking I can see a scenario where the application is creating > a > file and using a reader thread and a writer thread on the same file > handle. I > would want to protect driver wide resources but allow parallel reads and > writes. What is the implementation for this? consider old school > fopen("COM1") > > Asaf > > > > "Maxim S. Shatskih" wrote: > >> > My test application does not use FILE_FLAG_OVERLAPPED because my user >> > is not >> > used to it. >> > The device might receive other requests, mainly Create File / Close >> > Handle / >> > Cleanup, and power, so basically I do need device level synchronization >> > as >> > well. >> > Currently the synchronization scope is Queue level, but this without >> > doron's >> > solution is only device wide lock. >> >> So what? You need delice-level synchronization, and the KMDF queue gives >> you this. All is OK. >> >> And, if you need file-level synchronization, then just never use >> FILE_FLAG_OVERLAPPED, and all IRPs sent to this file object will be >> serialized by IO. >> >> -- >> Maxim S. Shatskih >> Windows DDK MVP >> maxim(a)storagecraft.com >> http://www.storagecraft.com >> >> . >>
From: Pavel A. on 19 Aug 2010 19:26
"Abhishek Ram [MSFT]" <abhisram(a)online.microsoft.com> wrote in message news:#T0zio#PLHA.2064(a)TK2MSFTNGP05.phx.gbl... >> Generally speaking I can see a scenario where the application is creating >> a >> file and using a reader thread and a writer thread on the same file >> handle. I >> would want to protect driver wide resources but allow parallel reads and >> writes. What is the implementation for this? consider old school >> fopen("COM1") > > If your application wants to have parallel reads and writes on the same > file handle, it needs to specify FILE_FLAG_OVERLAPPED. What if he opens a *new* handle (creating a new file object) for each application thread? Then threads won't block each other? Of course, the driver will need to allow multiple creates coming from one app. -- pa >Please see the documentation for CreateFile, specifically the documentation >of this flag: > "If this flag is specified, the file can be used for simultaneous read and > write operations. > If this flag is not specified, then I/O operations are serialized, even if > the calls to the read and write functions specify an OVERLAPPED > structure." > > > "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > news:4C9B7831-31E7-4C72-9054-AC23253F375E(a)microsoft.com... >> I need driver-wide synchronization to protect FO creation and cleanup. >> On the other hand I don't want an application using ReadFile on a COM >> port >> to block the entire driver from working. At least block only the >> application >> that did the read, not all the applications using the device. >> >> My real scenario is that I am keeping an internal read queue and the >> application reads periodically all the collected data (I know that there >> is >> always data to read). >> >> Generally speaking I can see a scenario where the application is creating >> a >> file and using a reader thread and a writer thread on the same file >> handle. I >> would want to protect driver wide resources but allow parallel reads and >> writes. What is the implementation for this? consider old school >> fopen("COM1") >> >> Asaf >> >> >> >> "Maxim S. Shatskih" wrote: >> >>> > My test application does not use FILE_FLAG_OVERLAPPED because my user >>> > is not >>> > used to it. >>> > The device might receive other requests, mainly Create File / Close >>> > Handle / >>> > Cleanup, and power, so basically I do need device level >>> > synchronization as >>> > well. >>> > Currently the synchronization scope is Queue level, but this without >>> > doron's >>> > solution is only device wide lock. >>> >>> So what? You need delice-level synchronization, and the KMDF queue gives >>> you this. All is OK. >>> >>> And, if you need file-level synchronization, then just never use >>> FILE_FLAG_OVERLAPPED, and all IRPs sent to this file object will be >>> serialized by IO. >>> >>> -- >>> Maxim S. Shatskih >>> Windows DDK MVP >>> maxim(a)storagecraft.com >>> http://www.storagecraft.com >>> >>> . >>> |