Submission is distinct from completion
Reading files or exchanging network data can require waiting on devices or communication. An asynchronous interface submits work first and obtains completion separately, allowing that wait to overlap with other activities.
POSIX AIO queues requests through interfaces such as aio_read, checks their status with aio_error, and obtains completed results through aio_return. Arranging a request and receiving the requested data are separate stages, with failures potentially reported through completion handling.
References: [1]
Outstanding operations retain state requirements
While work is outstanding, the program retains information needed to associate a result with its consumer. A POSIX AIO control block identifies the file, offset, buffer, and notification arrangement, which can involve a signal, a thread, or no active notification.
Asynchrony does not eliminate buffer-lifetime requirements. The Linux POSIX AIO documentation requires control and data buffers to remain valid and unchanged while an operation is in progress. Cancellation is an attempted operation too; consumers must still establish the resulting state before reclaiming associated resources.
References: [1]
Asynchronous interfaces can have different implementations
An asynchronous result does not establish an entirely kernel-driven implementation. The Linux manual describes glibc POSIX AIO using userspace threads; an event loop can likewise delegate a blocking function to an executor.
Performance analysis must distinguish the interface, waiting mechanism, and actual threads or other resources used underneath. Asynchrony improves the organization of waits without removing required data transfer or ensuring that ever more concurrent requests improve throughput.