用两种类型的输入/输入出IO：同步和异步。异步IO也被 成为重叠IO。
在同步文件IO中，一个线程启动一个IO操作，立即进行登台状态知道请求结束。
异步IO请求通过一个合适的函数调用对内核发起请求。如果这个请求被内核接受，调用线程继续处理其他工作指导内核通知这个线程操作完成了。它然后终端当前的工作，处理来自IO操作的数据。
灵芝同步机制可以解释为下图：
传统上，IO请求被认为要花费大量时间，比如刷新或者更新大型数据库或者一个缓慢的交互连接，异步IO是一个优化处理的好方法。然而，对于相对较快的IO操作，提前处理内核IO请求和内核信号可能使得异步IO收获甚小，特别的是很多快速IO操作。在这种情况下，同步IO更好点。
如果一个文件或者设备为同步IO打开，之后的函数调用会阻塞调用线程的执行，知道一下事件发生：
- The I/O operation completes (in this example, a data write).
- IO请求完成。比如，写数据
- IO错误发生。
- 调用自身发生错误
- 另外一个线程调用CancelSynchronousIo函数，这将终止这个线程的IO调用，因此失败。
- 阻塞线程被系统终止。
在一些情况下，这种耽搁可能是不可接受的，因此设计者应该考虑带有适当线程同步的异步IO，比如完成端口。
A process opens a file for asynchronous I/O in its call to CreateFile by
specifying the FILE_FLAG_OVERLAPPED flag
in thedwFlagsAndAttributes parameter.
If FILE_FLAG_OVERLAPPED is
not specified, the file is opened for synchronous I/O. When the file has been opened for asynchronous I/O, a pointer to an OVERLAPPED structure
is passed into the call toReadFile and WriteFile.
When performing synchronous I/O, this structure is not required in calls to ReadFile andWriteFile.
Note If a file or device is opened for asynchronous I/O, subsequent calls to functions such as WriteFile using
that handle generally return immediately but can also behave synchronously with respect to blocked execution. For more information, see http://support.microsoft.com/kb/156932.
Although CreateFile is
the most common function to use for opening files, disk volumes, anonymous pipes, and other similar devices, I/O operations can also be performed using a handle typecast from other system objects such as a socket created by the socket or accept functions.
Handles to directory objects are obtained by calling the CreateFile function
with the FILE_FLAG_BACKUP_SEMANTICSattribute. Directory handles are almost never used—backup applications are one of the few applications that will typically use them.
After opening the file object for asynchronous I/O, an OVERLAPPED structure
must be properly created, initialized, and passed into each call to functions such as ReadFile and WriteFile.
Keep the following in mind when using theOVERLAPPED structure
in asynchronous read and write operations:
- Do not deallocate or modify the OVERLAPPED structure
or the data buffer until all asynchronous I/O operations to the file object have been completed. - If you declare your pointer to the OVERLAPPED structure
as a local variable, do not exit the local function until all asynchronous I/O operations to the file object have been completed. If the local function is exited prematurely, theOVERLAPPED structure will go out of scope and it will be inaccessible
to any ReadFile or WriteFile functions
it encounters outside of that function.
You can also create an event and put the handle in the OVERLAPPED structure;
the wait
functions can then be used to wait for the I/O operation to complete by waiting on the event handle.
As previously stated, when working with an asynchronous handle, applications should use care when making determinations about when to free resources associated with a specified I/O operation on that handle. If the handle is deallocated prematurely, ReadFile or WriteFile may
incorrectly report that the I/O operation is complete. Further, theWriteFile function will sometimes return TRUE with a GetLastError value
of ERROR_SUCCESS, even though it is using an asynchronous handle (which can also return FALSE with ERROR_IO_PENDING). Programmers accustomed to synchronous I/O design will usually release data buffer resources
at this point because TRUE and ERROR_SUCCESSsignify the operation is complete. However, if I/O
completion ports are being used with this asynchronous handle, a completion packet will also be sent even though the I/O operation completed immediately. In other words, if the application frees resources after WriteFile returns TRUE with ERROR_SUCCESS in
addition to in the I/O completion port routine, it will have a double-free error condition. In this example, the recommendation would be to allow the completion port routine to be solely responsible for all freeing operations for such resources.
The system does not maintain the file pointer on asynchronous handles to files and devices that support file pointers (that is, seeking devices), therefore the file position must be passed to the read and write functions in the related offset data members of
the OVERLAPPED structure.
For more information, see WriteFile and ReadFile.
File pointer position for a synchronous handle is maintained by the system as data is read or written and can also be updated using the SetFilePointer or SetFilePointerEx function.
An application can also wait on the file handle to synchronize the completion of an I/O operation, but doing so requires extreme caution. Each time an I/O operation is started, the operating system sets the file handle to the nonsignaled state. Each time an
I/O operation is completed, the operating system sets the file handle to the signaled state. Therefore, if an application starts two I/O operations and waits on the file handle, there is no way to determine which operation is finished when the handle is set
to the signaled state. If an application must perform multiple asynchronous I/O operations on a single file, it should wait on the event handle in the specific OVERLAPPED structure
for each I/O operation, rather than on the common file handle.
To cancel all pending asynchronous I/O operations, use either:
- CancelIo—this
function only cancels operations issued by the calling thread for the specified file handle. - CancelIoEx—this
function cancels all operations issued by the threads for the specified file handle.
Use CancelSynchronousIo to
cancel pending synchronous I/O operations.
The ReadFileEx and WriteFileEx functions
enable an application to specify a routine to execute (seeFileIOCompletionRoutine)
when the asynchronous I/O request is completed.