Synchronous I/O occurs while you wait. Applications processing cannot continue until the I/O operation is complete.
In contrast, asynchronous I/O operations run in the background and do not block user applications. This improves performance, because I/O operations and applications processing can run simultaneously.
Many applications, such as databases and file servers, take advantage of the ability to overlap processing and I/O. These asynchronous I/O operations use various kinds of devices and files. Additionally, multiple asynchronous I/O operations may run at the same time on one or more devices or files.
Each asynchronous I/O request has a corresponding control block in the application's address space. When an asynchronous I/O request is made, a handle is established in the control block. This handle is used to retrieve the status and the return values of the request.
The following topics pertain to asynchronous I/O:
Functions provided by the asynchronous I/O facilities are:
The fundamental data structure associated with all asynchronous I/O operations is struct aiocb. Within this structure is the aio_offset field which is used to specify the offset for an I/O operation.
The default asynchronous I/O interfaces are limited to an offset of 2G minus 1 due to the signed 32-bit definition of aio_offset . To overcome this limitation, a new aio control block with a signed 64-bit offset field and a new set of asynchronous I/O interfaces have been defined beginning with AIX Version 4.2.1.
The large offset-enabled asynchronous I/O interfaces are available under the _LARGE_FILES compilation environment and under the _LARGE_FILE_API programming environment. For further information, see "Writing Programs Which Access Large Files" in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.
Under the _LARGE_FILES compilation environment in AIX Version 4.2.1 or later, asynchronous I/O applications written to the default interfaces see the following redefinitions:
|Item||Redefined To Be||Header File|
|struct aiocb||struct aiocb64||sys/aio.h|
For information on using the _LARGE_FILES environment, see "Porting Applications to the Large File Environment" in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.
In the _LARGE_FILE_API environment, the 64-bit API interfaces are visible. This environment requires recoding of applications to the new 64-bit API name. For further information on using the _LARGE_FILE_API environment, see "Using the 64-Bit File System Subroutines" in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.
After issuing an I/O request, the user application can proceed without being blocked while the I/O operation is in progress. The I/O operation occurs while the application is running. Specifically, when the application issues an I/O request, the request is queued. The application can then resume running before the I/O operation is initiated.
To manage asynchronous I/O, each asynchronous I/O request has a corresponding control block in the application's address space. This control block contains the control and status information for the request. It can be used again when the I/O operation is completed.
After issuing an asynchronous I/O request, the user application can determine when and how the I/O operation is completed. This information is provided in three ways:
The application can periodically poll the status of the I/O operation. The status of each I/O operation is provided in the application's address space in the control block associated with each request. Portable applications can retrieve the status by using the aio_error subroutine.
Asynchronously notifying the I/O completion is done by signals. Specifically, an application may request that a SIGIO signal be delivered when the I/O operation is complete. To do this, the application sets a flag in the control block at the time it issues the I/O request. If several requests have been issued, the application can poll the status of the requests to determine which have actually completed.
The third way to determine whether an I/O operation is complete is to let the calling process become blocked and wait until at least one of the I/O requests it is waiting for is complete. This is similar to synchronous style I/O. It is useful for applications that, after performing some processing, need to wait for I/O completion before proceeding.
I/O requests can be canceled if they are cancelable. Cancellation is not guaranteed and may succeed or not depending upon the state of the individual request. If a request is in the queue and the I/O operations have not yet started, the request is cancellable. Typically, a request is no longer cancelable when the actual I/O operation has begun.
Note: The 64-bit APIs are available beginning with AIX Version 4.2.1.
The following subroutines are provided for performing asynchronous I/O:
|aio_cancel or aio_cancel64||Cancels one or more asynchronous I/O requests.|
|aio_error or aio_error64||Retrieves the error status of an I/O request.|
|lio_listio or lio_listio64||Initiates multiple asynchronous read and write operations.|
|aio_read or aio_read64||Reads asynchronously from a file.|
|aio_return or aio_return64||Retrieves the return value of an I/O request.|
|aio_suspend or aio_suspend64||Blocks until an asynchronous I/O is completed.|
|aio_write or aio_write64||Writes asynchronously to a file.|
Note: These subroutines may change to conform with the IEEE POSIX 1003.4 interface specification.
An application may issue several asynchronous I/O requests on the same file or device. However, since the I/O operations are performed asynchronously, the order in which they are handled may not be the order in which the I/O calls were made. The application must enforce ordering of its own I/O requests if ordering is required.
Priority among the I/O requests is not currently implemented. The aio_reqprio field in the control block is currently ignored.
For files that support seek operations, seeking is allowed as part of the asynchronous read or write operations. The whence and offset fields are provided in the control block of the request to set the seek parameters. The seek pointer is updated when the asynchronous read or write call returns.
The following existing subroutines are affected by asynchronous I/O:
If the application closes a file, or calls the _exit or exec subroutines while it has some outstanding I/O requests, the requests are canceled. If they cannot be canceled, the application is blocked until the requests have completed. When a process calls the fork subroutine, its asynchronous I/O is not inherited by the child process.
One fundamental limitation in asynchronous I/O is page hiding. When an unbuffered (raw) asynchronous I/O is issued, the page that contains the user buffer is hidden during the actual I/O operation. This ensures cache consistency. However, the application may access the memory locations that fall within the same page as the user buffer. This may cause the application to block as a result of a page fault. To alleviate this, allocate page aligned buffers and do not touch the buffers until the I/O request using it has completed.
You can change attributes relating to asynchronous I/O using the chdev command or SMIT. Likewise, you can use SMIT to configure and remove (unconfigure) asynchronous I/O. (Alternatively, you can use the mkdev and rmdev commands to configure and remove asynchronous I/O). To start SMIT at the main menu for asynchronous I/O, enter smit aio .
The aio_cancel or aio_cancel64 subroutine, aio_error or aio_error64 subroutine, aio_read or aio_read64 subroutine, aio_return or aio_return64 subroutine, aio_suspend or aio_suspend64 subroutine, aio_write or aio_write64 subroutine, and lio_listio or lio_listio64 subroutine.
The chdev command, mkdev and rmdev command.
System Management Interface Tool (SMIT): Overview in AIX Version 4.3 System Management Guide: Operating System and Devices.