I’m a little confused about how to use an auto-reset event. I open my device with the FILE_FLAG_OVERLAPPED flag. When making DevideIOControl calls I pass a valid lpOverlapped argument. My concern is what to do after this point. The code I have been given checks for an error using GetLastError. If there is an IO_PENDING return value it will call GetOverlappedResult with TRUE as the value for bWait. My understanding is that when completed the IOControl call with signal the event causing GetOverlappedResult to complete. I believe GetOverlappedResult will also reset the event but I’m not clear on this point. The code I have, once returned from GetOverlappedResult, will check the return value for an error.
My concerns are:
1)Does GetOverlappedResult cause the auto-reset? I recall reading a wait function will auto-reset the event and the wait argument is true.
2)And can the call to GetLastError after the DeviceIOControl call already be finished and return no IO_PENDING error? In which case GetOverlappedResult is not called at all and the event doesn’t get reset.
err = DeviceIoControl(…, pXDev->pOverlappedMisc);
if(!err)
{
error = GetLastError();
switch (error)
{
case e_Err_NoError:
break;
case ERROR_IO_PENDING:
err = GetOverlappedResult(…, pXDev->pOverlappedMisc,
…, TRUE); // block
if(!err)
{
error = GetLastError();
return e_Err_MiscError;
}
break;
default:
return e_Err_MiscError;
}
}
It has worked but I think it is just a matter of luck to this point. Should I add a manual reset to occur if the first GetLastError() call returns no error? Or should I be doing something different all together?
No example I find seems to handle a scenario where DeviceIoControl doesn’t return pending or some other error. I did find one that loops the GetOverlappedResult call until complete because they use FALSE as the bWait argument. After this they do a manual reset but I don’t know if they are using a manual reset because they defined it that way or because GetOverlappedResult doesn’t wait. And once again they don’t reset if DeviceIoControl returns no error. But they always check for an error so I guess it doesn’t have to be an error. In this case why wouldn’t you reset the event?
xxxxx@yahoo.com wrote:
I’m a little confused about how to use an auto-reset event. I open my device with the FILE_FLAG_OVERLAPPED flag. When making DevideIOControl calls I pass a valid lpOverlapped argument. My concern is what to do after this point. The code I have been given checks for an error using GetLastError. If there is an IO_PENDING return value it will call GetOverlappedResult with TRUE as the value for bWait. My understanding is that when completed the IOControl call with signal the event causing GetOverlappedResult to complete. I believe GetOverlappedResult will also reset the event but I’m not clear on this point. The code I have, once returned from GetOverlappedResult, will check the return value for an error.
My concerns are:
1)Does GetOverlappedResult cause the auto-reset? I recall reading a wait function will auto-reset the event and the wait argument is true.
2)And can the call to GetLastError after the DeviceIOControl call already be finished and return no IO_PENDING error? In which case GetOverlappedResult is not called at all and the event doesn’t get reset.
GetLastError just fetches the error code that was stored by the failed
DeviceIoControl call. Nothing gets rechecked here, so it doesn’t matter
whether the state has changed. I would argue that the e_Err_NoError
case is superfluous here because of that, but that’s neither here nor there.
As for the rest, I’m not sure what you are worried about. If the event
doesn’t get reset, so what? It’s not like you are leaking resources.
DeviceIoControl will automatically reset the event when it starts.
It has worked but I think it is just a matter of luck to this point. Should I add a manual reset to occur if the first GetLastError() call returns no error? Or should I be doing something different all together?
No, this is pretty much the correct model.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@yahoo.com wrote:
No example I find seems to handle a scenario where DeviceIoControl doesn’t return pending or some other error.
I usually do that, just in case the driver returns success immediately,
but not all drivers are capable of that. Basically, the possible cases are:
- DeviceIoControl returns success. Hooray, all done.
- DeviceIoControl returns error – call GetLastError.
2a. GetLastError returns ERROR_IO_PENDING. Do other work, then
call GetOverlappedResult.
2a1. GetOverlappedResult returns success. Hooray, all done.
2a1. GetOverlappedResult returns error. Give up, go home.
2b. GetLastError is something other than ERROR_IO_PENDING. That’s
an error. Give up, go home.
I did find one that loops the GetOverlappedResult call until complete because they use FALSE as the bWait argument. After this they do a manual reset but I don’t know if they are using a manual reset because they defined it that way or because GetOverlappedResult doesn’t wait. And once again they don’t reset if DeviceIoControl returns no error. But they always check for an error so I guess it doesn’t have to be an error. In this case why wouldn’t you reset the event?
Because there is no need to do so. If you’re going to reuse the event,
DeviceIoControl will reset it. If you are just going to delete the
event, then it doesn’t matter what state it’s in.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks. I didn’t realize the DeviceIOControl would reset the event on subsequent calls. I couldn’t find anything about the call resetting the event in the description on the msdn site.
xxxxx@yahoo.com wrote:
Thanks. I didn’t realize the DeviceIOControl would reset the event on subsequent calls. I couldn’t find anything about the call resetting the event in the description on the msdn site.
There’s a note on the page describing the OVERLAPPED structure that says
“Functions such as *ReadFile*
http: and
WriteFile
http: set
this handle to the nonsignaled state before they begin an I/O
operation.” The astute reader will note that DeviceIoControl is not
mentioned, but given the wording on the rest of the page, I’m 99%
confident they are simply using those two as example to refer to all 6
or 8 functions that take an OVERLAPPED structure.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:></http:>
the documentation doesn’t state that explicitly, but looks like it is
implied:
http://msdn.microsoft.com/en-us/library/ms684342(VS.85).aspx
look at description of hEvent field.
wrote in message news:xxxxx@ntdev…
> Thanks. I didn’t realize the DeviceIOControl would reset the event on
> subsequent calls. I couldn’t find anything about the call resetting the
> event in the description on the msdn site.
>
They do. For curiosity I checked it and the event is cleared for
DeviceIoControl(), too. This is what any sane programmer would do. OTOH,
paranoid programmer calling such a function can always manually reset
the event just before the call. Or never reuse event and always create
new one (useful when one writes synchronous wrappers over async calls).
For OP: note also following paragraph from docs. Auto-reset event works
in your case but it can be better to use manual reset event. Just for
the case you or somebody else changes the code later and it can stop
working. Waiting for event followed by GetOverlappedResult() call is
used when you need to implement timeouts.
Functions such as GetOverlappedResult and the synchronization wait
functions reset auto-reset events to the nonsignaled state. Therefore,
you should use a manual reset event; if you use an auto-reset event,
your application can stop responding if you wait for the operation to
complete and then call GetOverlappedResult with the bWait parameter set
to TRUE.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Saturday, July 03, 2010 2:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] GetOverlappedResult
xxxxx@yahoo.com wrote:
> Thanks. I didn't realize the DeviceIOControl would reset
the event on subsequent calls. I couldn't find anything
about the call resetting the event in the description on the
msdn site.
There's a note on the page describing the OVERLAPPED
structure that says
"Functions such as *ReadFile*
http: and
> WriteFile
> http: set
> this handle to the nonsignaled state before they begin an I/O
> operation." The astute reader will note that DeviceIoControl is not
> mentioned, but given the wording on the rest of the page, I'm 99%
> confident they are simply using those two as example to refer to all 6
> or 8 functions that take an OVERLAPPED structure.
>
> --
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> ---
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> OSR Seminars – OSR
>
> To unsubscribe, visit the List Server section of OSR Online
> at ListServer/Forum
></http:></http:>
> 1)Does GetOverlappedResult cause the auto-reset? I recall reading a wait function will auto-reset
the event and the wait argument is true.
Are you reusing the same event for several IRPs? then the races are unavoidable I think.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com