https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx

https://en.wikipedia.org/wiki/Asynchronous_I/O

Input and output are inherently slow compared with other processing due to factors such as the following:

Delays caused by track and sector seek time on random access devices, such as disks  Delays caused by the relatively slow data transfer rate between a physical device and system memory  Delays in network data transfer using file servers, storage area networks, and so on

All I/O in previous examples has been thread-synchronous, so that the entire thread waits until the I/O operation completes. 

This chapter shows how a thread can continue without waiting for an operation to complete—that is, threads can perform asynchronous I/O. Examples illustrate the different techniques available in Windows. 

Overlapped I/O

The first requirement for asynchronous I/O, whether overlapped or extended, is to set the overlapped attribute of the file or other handle. Do this by specifying the flag on the  or other call that creates the file, named pipe, or other handle. Sockets (Chapter 13), whether created by or , have the attribute set by default. An overlapped socket can be used asynchronously in all Windows versions. Until now, overlapped structures have only been used with  and as an alternative to  (Chapter 3), but they are essential for overlapped I/O. These structures are optional parameters on four I/O functions that can potentially block while the operation completes:

ReadFIle

WriteFile

TransactNamedPipe

ConnectNamePipe

Recall that when you’re specifying  as part of  (for ) or as part of  (for ), the pipe or file is to be used only in overlapped mode. Overlapped I/O does not work with anonymous pipes.

Consequences of Overlapped I/O Overlapped I/O is asynchronous. There are several consequences when starting an overlapped I/O operation.

I/O operations do not block. The system returns immediately from a call to ReadFIle, WriteFIle,TransactNamedPipe , or .

  A returned  value does not necessarily indicate failure because the I/O operation is most likely not yet complete. In this normal case, GetlastError() will return , indicating no error. Windows provides a different mechanism to indicate status.

 

The returned number of bytes transferred is also not useful if the transfer is not complete. Windows must provide another means of obtaining this information.  The program may issue multiple reads or writes on a single overlapped file handle. Therefore, the handle’s file pointer is meaningless. There must be another method to specify file position with each read or write. This is not a problem with named pipes, which are inherently sequential.  The program must be able to wait (synchronize) on I/O completion. In case of multiple outstanding operations on a single handle, it must be able to determine which operation has completed. I/O operations do not necessarily complete in the same order in which they were issued.

http://www.cppblog.com/Lee7/archive/2008/01/07/40650.html

http://www.cnblogs.com/felove2013/articles/3942058.html

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365601(v=vs.85).aspx