Don
Sat Jul 02 08:12:56 CDT 2005
If you think about this you will see that OS has to do if the way Max
describes. If you do not use OVERLAPPED I/O you are expecting things to
occur in the order you request them. Since drivers are inherently
asynchronous this order has to be enforced by the upper layers of the OS, by
releasing only one I/O at a time to a driver.
Note, never try to rely on this in your driver, you have no control over a
users ability to use OVERLAPPED I/O so designing for synchronous I/O is
always a bug.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
"poltrone" <nospam@nospam.invalid> wrote in message
news:3inhfeFlu4rlU1@uni-berlin.de...
> Hi Maxim,
>
> i never heard of this before and i'm quite curious about that.
> Are you saying that the IO manager won't let a synchronous DeviceIOControl
> pass through to the driver if another thread using the same handle has
> a synchronous DeviceIOControl pending?
>
> poltrone
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> schrieb im Newsbeitrag
> news:u1Uu3gvfFHA.1480@TK2MSFTNGP10.phx.gbl...
>> Threads doing IO calls on the same file handle are serialized if the
>> IO is
>> not overlapped. So, 32 threads or 1 - no effect :)
>> Use overlapped IO.
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>>
http://www.storagecraft.com
>>
>> "Soquel Dude" <ImInSoquel@nospam.nospam> wrote in message
>> news:edJeGfqfFHA.3256@TK2MSFTNGP12.phx.gbl...
>>> I've written an NDIS IM driver that forwards notifications to a
>>> user-mode
>>> app via a pended IOCTL. The app has 32 threads that simply call
>>> DeviceIoControl and then queue the notification up for another consumer
>>> thread.
>>>
>>> The problem that I'm seeing is that under heavy stress, where the driver
>>> needs to notify the app, I see the number of IOCTLs plumbed by the app
>>> stop,
>>> with the result that the driver runs out of pending IOCTLS/IRPs.
>>>
>>> Each thread of the user mode app calls DeviceIoControl() in a
>>> non-overlapped
>>> manner. Would calling this with an overlapped structure (and opening the
>>> file with FILE_FLAG_OVERLAPPED) help?
>>>
>>>
>>
>>
>
>