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

"Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message 
news:6D71B953-80CB-43AA-BA78-3955C288394C@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
 

As mentioned in Pavel's response, automatic synchronization is not based on 
FileObject. Rather, the callbacks listed in the table on that page are 
synchronized with respect to each other, either at the device-level or at 
the queue-level, depending on what you choose.

"Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message 
news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> 

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@Shelly.co.il> wrote in message 
> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
>  
> 
> .
> 

> Is there any lock object attached to the File Object?

Yes, there is, used to synchronize threads on non-overlapped FO and thus =
to protect ->CurrentByteOffset from races.

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.com

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@Shelly.co.il> wrote in message 
news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
>> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
>>
>>
>> .
>> 

Hi Maxim,

Thanks. Is this lock something that I can use as a user of KMDF?

Asaf


"Maxim S. Shatskih" wrote:

> > Is there any lock object attached to the File Object?
> 
> Yes, there is, used to synchronize threads on non-overlapped FO and thus to protect ->CurrentByteOffset from races.
> 
> -- 
> Maxim S. Shatskih
> Windows DDK MVP
> maxim@storagecraft.com
> http://www.storagecraft.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@Shelly.co.il> wrote in message 
> news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> >>
> >>
> >> .
> >> 
> .
> 

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@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@Shelly.co.il> wrote in message
> news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> >>
> >>
> >> .
> >>
> .
> 

> 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.

Are you saying your driver does not receive any other request for that 
device object? Or is it for that file object?
What synchronization scope did you set in the case that you observed this? 
Also does the application use FILE_FLAG_OVERLAPPED when it opens the handle?

"Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message 
news:EEF1F838-3A0A-4788-816C-DECC903FC106@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@Shelly.co.il> wrote in message
>> news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
>> >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
>> >>
>> >>
>> >> .
>> >>
>> .
>> 

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@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@Shelly.co.il> wrote in message
> > news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> > >>
> > >>
> > >> .
> > >>
> > .
> > 
> 
> .
> 

Hi Abhishek,

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.

Honestly I would expect WDF to forward the request to the File Object 
specific queue automatically.

Thanks for all the help,
Asaf


"Abhishek Ram [MSFT]" wrote:

> > 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.
> 
> Are you saying your driver does not receive any other request for that 
> device object? Or is it for that file object?
> What synchronization scope did you set in the case that you observed this? 
> Also does the application use FILE_FLAG_OVERLAPPED when it opens the handle?
> 
> "Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message 
> news:EEF1F838-3A0A-4788-816C-DECC903FC106@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@Shelly.co.il> wrote in message
> >> news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> >> >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> >> >>
> >> >>
> >> >> .
> >> >>
> >> .
> >> 
> .
> 

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@Shelly.co.il> wrote in message 
news:50F8C3CA-EF1C-4AE0-81DE-0D56F9ACD884@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@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@Shelly.co.il> wrote in message
>> > news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
>> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
>> > >>
 

> However, the blocking on  sync handles occurs in user mode.

In kernel mode in IopSynchronousServiceTail

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.com

> My test application does not use FILE_FLAG_OVERLAPPED because my user =
is not=20
> used to it.
> The device might receive other requests, mainly Create File / Close =
Handle /=20
> Cleanup, and power, so basically I do need device level =
synchronization as=20
> well.
> Currently the synchronization scope is Queue level, but this without =
doron's=20
> 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.

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.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

"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@Shelly.co.il> wrote in message 
> news:50F8C3CA-EF1C-4AE0-81DE-0D56F9ACD884@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@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@Shelly.co.il> wrote in message
> >> > news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> >> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> >> > >>
>  
> 

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@storagecraft.com
> http://www.storagecraft.com
> 
> .
> 

> On the other hand I don't want an application using ReadFile on a COM =
port=20
> 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.

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.com

> 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@Shelly.co.il> wrote in message 
news:4C9B7831-31E7-4C72-9054-AC23253F375E@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@storagecraft.com
>> http://www.storagecraft.com
>>
>> .
>> 

"Abhishek Ram [MSFT]" <abhisram@online.microsoft.com> wrote in message 
news:#T0zio#PLHA.2064@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@Shelly.co.il> wrote in message 
> news:4C9B7831-31E7-4C72-9054-AC23253F375E@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@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>> .
>>> 

"Maxim S. Shatskih" <maxim@storagecraft.com.no.spam> wrote in message 
news:uCTEvq4PLHA.2692@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@storagecraft.com
> http://www.storagecraft.com
> 

"Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message 
news:D6A9E0AD-7639-4047-8F2F-2FFD38F6E308@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@Shelly.co.il> wrote in message
>> news:50F8C3CA-EF1C-4AE0-81DE-0D56F9ACD884@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@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@Shelly.co.il> wrote in message
>> >> > news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
>> >> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
>> >> > >>
>>
>> 

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@12fastmail34.fm> wrote in message 
news:584145E1-70DC-47D0-AC35-8E036631A82B@microsoft.com...
> "Abhishek Ram [MSFT]" <abhisram@online.microsoft.com> wrote in message 
> news:#T0zio#PLHA.2064@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@Shelly.co.il> wrote in message 
>> news:4C9B7831-31E7-4C72-9054-AC23253F375E@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@storagecraft.com
>>>> http://www.storagecraft.com
>>>>
>>>> .
>>>> 

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@Shelly.co.il> wrote in message 
> news:D6A9E0AD-7639-4047-8F2F-2FFD38F6E308@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@Shelly.co.il> wrote in message
> >> news:50F8C3CA-EF1C-4AE0-81DE-0D56F9ACD884@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@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@Shelly.co.il> wrote in message
> >> >> > news:4578B801-0376-498D-8046-2B6DE6AE9122@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@Shelly.co.il> wrote in message
> >> >> > >> news:6D71B953-80CB-43AA-BA78-3955C288394C@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
> >> >> > >>
> >>
> >> 

My driver will open the COM port just once but the User application is 
talking to the COM port via my driver..



"Maxim S. Shatskih" wrote:

> > 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@storagecraft.com
> http://www.storagecraft.com
> 
> .
> 

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@12fastmail34.fm> wrote in message 
> news:584145E1-70DC-47D0-AC35-8E036631A82B@microsoft.com...
> > "Abhishek Ram [MSFT]" <abhisram@online.microsoft.com> wrote in message 
> > news:#T0zio#PLHA.2064@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@Shelly.co.il> wrote in message 
> >> news:4C9B7831-31E7-4C72-9054-AC23253F375E@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@storagecraft.com
> >>>> http://www.storagecraft.com
> >>>>
> >>>> .
> >>>> 
> .
> 

"Asaf Shelly" <MSMediaForum@Shelly.co.il> wrote in message
news:2CEB94A2-FFAA-45B9-93E8-E01FB3AB3ADE@microsoft.com...
...........
> 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'.

Not sure if I completely understand this statement, but maybe you need
a better interface concept.

See http://www.osronline.com/showThread.cfm?link=188211
message #26

"you must never, ever, not even once, think that ReadFile, WriteFile, and/or
DeviceIoControl
are the *user visible* interfaces to your driver.  Do this, and it warps
your thinking
into trying to make this low-level interface "easy to use".  No, decide what
you want the upper-level user interface to look like, to the application
programmer.  Then writer a library that translates that into low-level calls
like DeviceIoControl. ...

There is a line between the effort we expend in kernel space and the effort
we expend in user space to make a piece of hardware work.  The user space
gets split between what the application writer *has* to see, and what you
can write as a library.  The smaller the kernel piece, the faster you get it
done, the more robust it is likely to be.  .............
So you design the API *first*, then figure out how you are going to map it
to
low-level calls, then figure out how you are going to get the performance
you need "
( Joseph Newcomer, co-author of the "Developing Windows NT Device Drivers"
book)

IMHO, "stupid users" is a misnomer. Our users are not stupid at all ;)
Instead, how about "users that don't want to care about boring
details" ?
They are not going to access low level interfaces at all, exactly because
these are encumbered with lot of boring details.
These folks should use higher level, more robust interfaces, like message
queues,
and automatic memory management.

Regards,
--pa