Asynchronous I/O

Threads-based Interface

The SVR4.2 MP version of Asynchronous I/O contains the following caveats:

Uses all POSIX interfaces including aio_suspend and aio_cancel.
Can implement Asynchronous I/O over all file types, not just raw disk slices and is implemented in the thread-based library libthread.
Does not need to use aio_memlock to lock memory.
Does not support lio_listio.

Threads-based interface operations

This section describes how the threads-based version of Asynchronous I/O operates on the following:

regular files
device files
STREAMS-based files.

It is not limited to specific file system types. Any device that supports read and write will accept asynchronous read and write requests.

The aio_read and aio_write interface routines correspond to the read and write system calls to support asynchronous read and write operations. These Asynchronous I/O operations are available with unbuffered as well as buffered I/O on those file system types that support unbuffered I/O.

Since unbuffered I/O is not available across all file system types, asynchronous unbuffered I/O will only be available on those file system types that support this capability.

CAUTION: It is important that multiple threads performing I/O to the same file cooperate since the order of operations is non-deterministic. Even one thread should be careful not to mix synchronous I/O requests with asynchronous I/O requests (with or without buffering) since the order of operations is implementation dependent.

The asynchronous read and write interfaces allow you to specify the file offset indicating where the I/O should begin. It is possible to specify absolute file offsets for each I/O request and this type of access is defined to be random. It is also possible to indicate that the I/O should begin at the current file offset. Sequential access is defined to be multiple I/O requests from a single thread of control to the same file descriptor indicating that I/O should begin at the current file offset. See the section entitled Asynchronous I/O Control Block for more information.

Determining the value of the file pointer when Asynchronous I/O operations are in progress is difficult. Considering that there may be multiple outstanding asynchronous I/O operations, each of which may update the file pointer at any time, things may become complex for an application. An application should be careful not to mix calls to read and write or lseek, for example, with Asynchronous I/O operations. If sequential I/O is not requested, the order of I/O operations is implementation dependent. In general, until all asynchronous operations on a file are completed, the position of the file pointer is considered to be indeterminate.

An application can request cancellation of one or more Asynchronous I/O requests that the application had previously queued. The aio_cancel interface enables an application to cancel one or more outstanding Asynchronous I/O operations. Those that have not been started are canceled but those in progress may or may not be canceled.

An application can wait for Asynchronous I/O completion. If an application has completed all its other work, it may relinquish control of the CPU until some of its outstanding asynchronous I/O requests have completed.

An application can obtain completion status information by calling aio_error and aio_return.

NOTE: The completion of an asynchronous write on any device has the same semantics as a synchronous write to that device; for example, completion of a write to a STREAMS-based device means that the data has been copied into the stream's queue and does not imply that the data has been written to a device.

When an Asynchronous I/O request is made, the application can also request that it be notified when the I/O completes. This lets the application know immediately that the I/O has completed rather than having the application poll for completion status.

Single threaded and multithreaded applications

Asynchronous I/O may be used by single threaded or multithreaded applications.

In multithreaded applications, multiple threads within a process share the same address space and therefore have access to the Asynchronous I/O control blocks of any other thread within that process. For example, one thread may begin an asynchronous read on an open file and another thread within that process may use the aio_suspend interface to determine if that read operation has completed. If this occurs, the application must make sure that the cooperating threads are properly synchronized.