A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
Asynchronous I/O allows a process to initiate an I/O operation and continue execution without blocking until completion. The kernel delivers completion notification via signals, callbacks, or polling mechanisms. AIO is essential for high-concurrency servers and improves latency and throughput compared to blocking I/O with multiple threads.
From your study of I/O systems, you know the basic model: a process issues a system call like `read()` or `write()`, the kernel interacts with the hardware, and eventually the data is transferred. In the default blocking (synchronous) model, the process is suspended until the I/O completes — it literally sits idle while the disk spins or the network packet travels. For a simple program this is fine, but imagine a web server handling 10,000 simultaneous connections. If each connection blocks a thread waiting for network data, you need 10,000 threads, each consuming memory for its stack and adding context-switching overhead. This is the problem asynchronous I/O solves.
Asynchronous I/O (AIO) inverts the relationship between the process and the I/O operation. Instead of "start I/O, wait, get result," the model becomes "start I/O, go do other work, get notified when it's done." The process calls an asynchronous version of read or write, and the kernel immediately returns control. The process can then continue executing — processing other requests, performing computations, or issuing more I/O operations. When the hardware completes the transfer, the kernel notifies the process through one of several mechanisms: a signal (like an interrupt at the process level), a callback function that gets invoked, or a completion queue that the process can poll or wait on.
Different operating systems implement this in different ways. Linux offers `io_uring`, a modern high-performance interface where the application and kernel share ring buffers for submitting requests and receiving completions, minimizing system call overhead. Older Linux AIO (`libaio`) works primarily with direct I/O on files. Windows uses I/O Completion Ports (IOCP), where completed operations are queued and worker threads dequeue them. BSD systems use kqueue. An intermediate approach, often called non-blocking I/O with event notification (using `epoll`, `kqueue`, or `select`), doesn't make the I/O itself asynchronous but lets the process ask "which of my file descriptors are ready?" and then issue blocking reads only on descriptors that are guaranteed to return immediately.
The tradeoff is complexity. Blocking I/O produces straightforward sequential code: read, process, write. Asynchronous I/O requires the programmer to structure code around events and callbacks, splitting what was a linear operation into separate "start" and "complete" phases. This is why frameworks like Node.js (which uses an event loop over non-blocking I/O) and libraries like Python's `asyncio` exist — they provide programming models that make asynchronous code more manageable. The performance gains are substantial: a single thread using asynchronous I/O can handle thousands of concurrent connections with far less memory and context-switching overhead than the thread-per-connection model, which is why AIO underpins virtually every modern high-performance server.