Timeout Implementation

I have a USB device and WDM driver I've developed with heavy borrowing from
Oney's book. The device sends data to the host PC using a bulk IN pipe. The
driver buffers this data until requested by the User code.
I'd like to implement a mechanism whereby the user code can request data,
but if it's not available, it can can block up to a programmable timeout
delay, until the data is available.
This seems like a common need, but I'm unsure how to implement it. Should
the timeout be implemented in user or kernel mode? It seems I could do it
either way.

The method I'm considering is:
The user code makes the request via an IOCTL
If data is available, then the data is returned, with a STATUS_SUCCESS.
If no data is available, then the IRP is cached and STATUS_PENDING is
returned.
The user code completes if STATUS_SUCCESS was returned.
If STATUS_PENDING was returned, then the user code calls
WaitForSingleObject with the desired timeout
When data is available, the IRP is completed with the data and
STATUS_SUCCESS
If the user code times out, then I would cancel the IRP
(Is there a risk of a race here? What if my driver is completing the
IRP when the cancel occurs?)

Any general suggestions are welcome.
Thanks in advance for help,
Dennis

Doron
Mon Jan 02 19:00:52 CST 2006

the timeout is UM is the easiest. just like you have it, the timeout can
occur in WaitForSingleObject on the event that you passed in with the
OVERLAPPED structure. If the timeout occurs and then you call CancelIo, the
race is taken care of for you by the i/o manager. You must also handle the
situation where your cancel routine might be invoked right when you want to
complete the request, this you must handle in your driver (i would recommend
using a CSQ which handles most of the details for you).

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.


"db_from_mn" <dburns@rtessentials.com> wrote in message
news:a8OdnSmedrmbNyTeRVn-sA@comcast.com...
>I have a USB device and WDM driver I've developed with heavy borrowing
>from Oney's book. The device sends data to the host PC using a bulk IN
>pipe. The driver buffers this data until requested by the User code.
> I'd like to implement a mechanism whereby the user code can request data,
> but if it's not available, it can can block up to a programmable timeout
> delay, until the data is available.
> This seems like a common need, but I'm unsure how to implement it. Should
> the timeout be implemented in user or kernel mode? It seems I could do it
> either way.
>
> The method I'm considering is:
> The user code makes the request via an IOCTL
> If data is available, then the data is returned, with a STATUS_SUCCESS.
> If no data is available, then the IRP is cached and STATUS_PENDING is
> returned.
> The user code completes if STATUS_SUCCESS was returned.
> If STATUS_PENDING was returned, then the user code calls
> WaitForSingleObject with the desired timeout
> When data is available, the IRP is completed with the data and
> STATUS_SUCCESS
> If the user code times out, then I would cancel the IRP
> (Is there a risk of a race here? What if my driver is completing
> the IRP when the cancel occurs?)
>
> Any general suggestions are welcome.
> Thanks in advance for help,
> Dennis
>

Mark
Mon Jan 02 21:04:19 CST 2006

On Mon, 2 Jan 2006 16:32:59 -0600, "db_from_mn"
<dburns@rtessentials.com> wrote:

>I have a USB device and WDM driver I've developed with heavy borrowing from
>Oney's book. The device sends data to the host PC using a bulk IN pipe. The
>driver buffers this data until requested by the User code.
>I'd like to implement a mechanism whereby the user code can request data,
>but if it's not available, it can can block up to a programmable timeout
>delay, until the data is available.
>This seems like a common need, but I'm unsure how to implement it. Should
>the timeout be implemented in user or kernel mode? It seems I could do it
>either way.
>
>The method I'm considering is:
> The user code makes the request via an IOCTL
> If data is available, then the data is returned, with a STATUS_SUCCESS.
> If no data is available, then the IRP is cached and STATUS_PENDING is
>returned.
> The user code completes if STATUS_SUCCESS was returned.
> If STATUS_PENDING was returned, then the user code calls
>WaitForSingleObject with the desired timeout
> When data is available, the IRP is completed with the data and
>STATUS_SUCCESS
> If the user code times out, then I would cancel the IRP
> (Is there a risk of a race here? What if my driver is completing the
>IRP when the cancel occurs?)
>

Yes of course obviously there is a race condition, however if you use
cancel safe queues in your driver the driver end of the race condition
should be correct.

What happens if the device isn't fed URBs on a timely basis? That
might be more important to how you implement the IO mechanism than who
times out when there is no data from the device.



=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Maxim
Tue Jan 03 04:03:38 CST 2006

> I'd like to implement a mechanism whereby the user code can request data,
> but if it's not available, it can can block up to a programmable timeout
> delay, until the data is available.

Why use any timeouts here? The usual semantic is to block forever, till the
handle will be closed (by cancellation due to process being killed too) or till
the data will arrive, or till the device will be detached.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

db_from_mn
Tue Jan 03 06:34:43 CST 2006

Hello Maxim,
It is true that in the normal case, it would be ok to block forever. But
there are situations where data is expected, and if it does not arrive in a
timely fashion, the user code must indicate an error condition.
Thanks for your comment,
Dennis

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eHVFX0EEGHA.140@TK2MSFTNGP12.phx.gbl...
>> I'd like to implement a mechanism whereby the user code can request data,
>> but if it's not available, it can can block up to a programmable timeout
>> delay, until the data is available.
>
> Why use any timeouts here? The usual semantic is to block forever, till
> the
> handle will be closed (by cancellation due to process being killed too) or
> till
> the data will arrive, or till the device will be detached.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

db_from_mn
Tue Jan 03 06:46:55 CST 2006

Hello Doron,
Thanks for your comments. I need to understand CSQs better. I will study
that. I find the whole topic of
queueing to be very confusing.
Thanks for you help,
Dennis

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%23$DQlEAEGHA.2040@TK2MSFTNGP14.phx.gbl...
> the timeout is UM is the easiest. just like you have it, the timeout can
> occur in WaitForSingleObject on the event that you passed in with the
> OVERLAPPED structure. If the timeout occurs and then you call CancelIo,
> the race is taken care of for you by the i/o manager. You must also handle
> the situation where your cancel routine might be invoked right when you
> want to complete the request, this you must handle in your driver (i would
> recommend using a CSQ which handles most of the details for you).
>
> 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.
>
>
> "db_from_mn" <dburns@rtessentials.com> wrote in message
> news:a8OdnSmedrmbNyTeRVn-sA@comcast.com...
>>I have a USB device and WDM driver I've developed with heavy borrowing
>>from Oney's book. The device sends data to the host PC using a bulk IN
>>pipe. The driver buffers this data until requested by the User code.
>> I'd like to implement a mechanism whereby the user code can request data,
>> but if it's not available, it can can block up to a programmable timeout
>> delay, until the data is available.
>> This seems like a common need, but I'm unsure how to implement it. Should
>> the timeout be implemented in user or kernel mode? It seems I could do it
>> either way.
>>
>> The method I'm considering is:
>> The user code makes the request via an IOCTL
>> If data is available, then the data is returned, with a
>> STATUS_SUCCESS.
>> If no data is available, then the IRP is cached and STATUS_PENDING is
>> returned.
>> The user code completes if STATUS_SUCCESS was returned.
>> If STATUS_PENDING was returned, then the user code calls
>> WaitForSingleObject with the desired timeout
>> When data is available, the IRP is completed with the data and
>> STATUS_SUCCESS
>> If the user code times out, then I would cancel the IRP
>> (Is there a risk of a race here? What if my driver is completing
>> the IRP when the cancel occurs?)
>>
>> Any general suggestions are welcome.
>> Thanks in advance for help,
>> Dennis
>>
>
>

db_from_mn
Tue Jan 03 07:01:27 CST 2006

Hello Mark,
Thanks for your comments. I need to understand CSQs better, and plan to
study them. I find the whole topic confusing.
You wondered about how I get data from the device in a timely manner. Well,
the way I'm doing it (right or wrong) is that
I create an IRP and associated URB that I use to request Bulk IN data from
the device. In the IRPs completion routine, I store the received data in a
buffer, and re-submit the URB.
The device returns data only when available. If none is available, then the
device will NAK the request.
Do you see an problem with this method?
Best regards, and thanks for your help,
Dennis

"Mark Roddy" <markr@hollistech.com> wrote in message
news:j0qjr1d61l9tv1damip724b73amgm6s4t1@4ax.com...
> On Mon, 2 Jan 2006 16:32:59 -0600, "db_from_mn"
> <dburns@rtessentials.com> wrote:
>
>>I have a USB device and WDM driver I've developed with heavy borrowing
>>from
>>Oney's book. The device sends data to the host PC using a bulk IN pipe.
>>The
>>driver buffers this data until requested by the User code.
>>I'd like to implement a mechanism whereby the user code can request data,
>>but if it's not available, it can can block up to a programmable timeout
>>delay, until the data is available.
>>This seems like a common need, but I'm unsure how to implement it. Should
>>the timeout be implemented in user or kernel mode? It seems I could do it
>>either way.
>>
>>The method I'm considering is:
>> The user code makes the request via an IOCTL
>> If data is available, then the data is returned, with a
>> STATUS_SUCCESS.
>> If no data is available, then the IRP is cached and STATUS_PENDING is
>>returned.
>> The user code completes if STATUS_SUCCESS was returned.
>> If STATUS_PENDING was returned, then the user code calls
>>WaitForSingleObject with the desired timeout
>> When data is available, the IRP is completed with the data and
>>STATUS_SUCCESS
>> If the user code times out, then I would cancel the IRP
>> (Is there a risk of a race here? What if my driver is completing
>> the
>>IRP when the cancel occurs?)
>>
>
> Yes of course obviously there is a race condition, however if you use
> cancel safe queues in your driver the driver end of the race condition
> should be correct.
>
> What happens if the device isn't fed URBs on a timely basis? That
> might be more important to how you implement the IO mechanism than who
> times out when there is no data from the device.
>
>
>
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP/2000 Consulting
> Device and Filesystem Drivers
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

Alexander
Tue Jan 03 11:11:47 CST 2006

If you don't get data in time, you don't have to cancel the request. Just
indicate it to the user (or let the user app to figure it out)..

The problem is that you might lose data that arrives during URB
cancellation.

"db_from_mn" <dburns@rtessentials.com> wrote in message
news:bMWdnT96-M7-8ifenZ2dnUVZ_sSdnZ2d@comcast.com...
> Hello Maxim,
> It is true that in the normal case, it would be ok to block forever. But
> there are situations where data is expected, and if it does not arrive in
> a timely fashion, the user code must indicate an error condition.
> Thanks for your comment,
> Dennis
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:eHVFX0EEGHA.140@TK2MSFTNGP12.phx.gbl...
>>> I'd like to implement a mechanism whereby the user code can request
>>> data,
>>> but if it's not available, it can can block up to a programmable timeout
>>> delay, until the data is available.
>>
>> Why use any timeouts here? The usual semantic is to block forever, till
>> the
>> handle will be closed (by cancellation due to process being killed too)
>> or till
>> the data will arrive, or till the device will be detached.
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com
>>
>
>

Maxim
Wed Jan 04 09:52:25 CST 2006

> Hello Maxim,
> It is true that in the normal case, it would be ok to block forever. But
> there are situations where data is expected, and if it does not arrive in a
> timely fashion, the user code must indicate an error condition.
> Thanks for your comment,
> Dennis

Then you have the whole can of worms with race issues. The potential races are
between a) normal queue execution b) timer c) cancellation. A bit hard, but
solvable.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com