Re: [ntdev] Re: [ntdev] Question about asynchronous IO

NTDEV
1

>>In general, drivers in windows are ASSUMED to have this support and applications either use overlapped IO or don’t. In modern Windows, a driver that does not support overlapped IO and IRP queuing is almost unheard of;

i think the user mode IO asynchronous operation and kernel driver’s IRP asynchronous processing, are completly 2 different stories. Even driver don’t support any IRP asynchronous processing, the user mode asynchronous is also supported, becase the support just comes from OS.

=================
Best Regards!
Zhang Pei
www.yiiyee.cn/blog

From: Marion Bond
Sent: ‎Wednesday‎, ‎August‎ ‎27‎, ‎2014 ‎6‎:‎01‎ ‎AM
To: Windows System Software Devs Interest List

There is no good reason not to implement IRP queuing for most drivers. KMDF makes this trivial and supports cancel too. In general, drivers in windows are ASSUMED to have this support and applications either use overlapped IO or don’t. In modern Windows, a driver that does not support overlapped IO and IRP queuing is almost unheard of; especially a new driver that isn’t for some custom embedded solution

Sent from Surface Pro

From: Pavel A.
Sent: ‎Tuesday‎, ‎August‎ ‎26‎, ‎2014 ‎5‎:‎41‎ ‎AM
To: Windows System Software Devs Interest List

On 26-Aug-2014 04:51, xxxxx@hotmail.com wrote:

If the application uses multi-thread to send the asynchronous IO request by FILE_FLAG_OVERLAPPED.
Who is responsible to queue these IRPs? IO manager?

There’s no queue on the application level.
If a file object is created without FILE_FLAG_OVERLAPPED,
only one request can be in at any time.
Other threads trying to send a request just will block until
the active request completes.

if there is no IRP queue, is it possible to implement asynchronous IO?

Yes, in a trivial way (the driver immediately fails all requests,
until the active one completes).

– pa

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

2

Peter

One small correction to your case 3:

  • App requests sync or async processing, driver provides sync processing. Result at app: SYNC.

This is the key point. If the driver (including any framework it is using) does not pend the IRP, then the thread does return up the callstack back into UM and allow the app to allow it to continue. If the driver does pend the IRP, then based on the parameters the app passed to the API, it may block until completion or return and allow it to continue.

Note that when an IOCP is in use, the completion may be dequed and have been entirely processed by another thread before the call has actually returned. This often happens on machines with many cores when the application requests (the default behaviour) of completion notifications for immediately successful IRPs.

As you note, the framework (provided by Microsoft, but not part of the OS) normally handles the pending transparently

Sent from Surface Pro

From: xxxxx@osr.com
Sent: ‎Wednesday‎, ‎August‎ ‎27‎, ‎2014 ‎11‎:‎09‎ ‎AM
To: Windows System Software Devs Interest List

Yes, they are.

No, this is not correct, if you mean to say that an asynchronous request from user-mode will be serviced asynchronously by the kernel driver.

Let’s talk WDM for a moment here, to avoid all confusion: If the driver gets an async request directly from user-mode (that is, a ReadFile sent with an overlapped structure), and if that driver then blocks in its dispatch routine… the calling thread will wait. This thread is not getting ascychronous service.

There are three cases, right?

  • App requests async processing, driver provides async processing. Result at app: ASYNC.
  • App requests sync processing, driver provides async processing. Result at app: SYNC.
  • App requests async processing, driver provides sync processing. Result at app: SYNC.

It can’t be any other way.

Now… if you consider how WDF makes this LOOK, the situation seems much easier. Because WDF places its WDFQUEUES ahead of the EvtIoXxx Event Processing Callbacks – this is VERY different to WDM where the driver is called in its dispatch entry point and responsible for doing something with the request (queue it or immediately process it).

Peter
OSR
@OSRDrivers

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer