From: Gerard Harkema on
In our USB KMDF driver we control a data-acquisition device. Data transfer is
a three stage action. First we send a command to the device, the the actual
data and after that we receive the status of the operation. We are using the
WdfUsbTargetPipeWriteSynchronously/WdfUsbTargetPipeReadSynchronously
functions to communicate whit our USB device. When we issue a DeviceIoControl
we receive the request in the default queue (WdfIoQueueDispatchParallel) and
the request is forwarded to an other Queue (WdfIoQueueDispatchSequential). De
we need extra syncronization to prevent other requests from "breaking in" in
the dispatching request.

Kind Regards,

Gerard
From: Doron Holan [MSFT] on
if all i/o to the device is going through the serial queue, you have the
synchronization you want. the serialized queue will act as a lock around
the access to the resource (your usb pipe)

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Gerard Harkema" <GerardHarkema(a)discussions.microsoft.com> wrote in message
news:D49E5E65-0A37-4B25-A383-B5D3029BBCE1(a)microsoft.com...
> In our USB KMDF driver we control a data-acquisition device. Data transfer
> is
> a three stage action. First we send a command to the device, the the
> actual
> data and after that we receive the status of the operation. We are using
> the
> WdfUsbTargetPipeWriteSynchronously/WdfUsbTargetPipeReadSynchronously
> functions to communicate whit our USB device. When we issue a
> DeviceIoControl
> we receive the request in the default queue (WdfIoQueueDispatchParallel)
> and
> the request is forwarded to an other Queue (WdfIoQueueDispatchSequential).
> De
> we need extra syncronization to prevent other requests from "breaking in"
> in
> the dispatching request.
>
> Kind Regards,
>
> Gerard