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: Pavel A. on 19 Aug 2010 19:28 "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:uCTEvq4PLHA.2692(a)TK2MSFTNGP05.phx.gbl... >> However, the blocking on sync handles occurs in user mode. > > In kernel mode in IopSynchronousServiceTail Ah. Really. It's damn hot here :( But regarding the app, this is practically same. -- pa > -- > Maxim S. Shatskih > Windows DDK MVP > maxim(a)storagecraft.com > http://www.storagecraft.com >
From: Pavel A. on 19 Aug 2010 19:36 "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:D6A9E0AD-7639-4047-8F2F-2FFD38F6E308(a)microsoft.com... > 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 Try to open a new handle for each app thread - each thread will then wait on its own file object, independently from each other. Regards, -- pa > "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: Abhishek Ram [MSFT] on 19 Aug 2010 20:04 Yes, if the threads were to use different file handles then they can do I/O simultaneously even without FILE_FLAG_OVERLAPPED. However, as you point out, the device should allow multiple handles to be opened to it. I believe serial ports are exclusive access devices, so they allow no more than one handle to be opened to them (as Maxim also mentioned in another post). "Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message news:584145E1-70DC-47D0-AC35-8E036631A82B(a)microsoft.com... > "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 >>>> >>>> . >>>>
From: Asaf Shelly on 23 Aug 2010 03:37 Hi Pavel, This is exactly the plan, I only want the driver to be protected from mistakes. The only way to communicate with a COM port is to open it once and use a background reader thread on the same file handle. It is a mistake waiting to happen. Regards, Asaf "Pavel A." wrote: > "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > news:D6A9E0AD-7639-4047-8F2F-2FFD38F6E308(a)microsoft.com... > > 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 > > Try to open a new handle for each app thread - > each thread will then wait on its own file object, independently from each > other. > > Regards, > -- pa > > > > "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 23 Aug 2010 03:48
This is my problem exactly. COM Port are opened once and used with multiple threads using blocking operations (ReadFile, WriteFile without overlapped). It is most probable that one of the users of this driver will use the same method when integrating in an old application that is currently using the COM port directly. The correct method is to use overlapped IO but I still think that the KMDF library should provide support for File Object isolation. Currently the scenario is that if I am using any out-of-the-box synchronization I am risking a situation of a single user application deadlocking the driver. For example if an application is using the driver to open a COM port which is not connected to a cable and then uses ReadFile on that handle then the lower level Serial driver will block to completion and would practically deny any communication from any user application. What I am looking for is not a solution to the problem, I am looking for a way to isolate the rest of the driver from the 'stupid user'. Thanks, Asaf "Abhishek Ram [MSFT]" wrote: > Yes, if the threads were to use different file handles then they can do I/O > simultaneously even without FILE_FLAG_OVERLAPPED. However, as you point out, > the device should allow multiple handles to be opened to it. I believe > serial ports are exclusive access devices, so they allow no more than one > handle to be opened to them (as Maxim also mentioned in another post). > > "Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message > news:584145E1-70DC-47D0-AC35-8E036631A82B(a)microsoft.com... > > "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 > >>>> > >>>> . > >>>> > . > |