Understanding the 5 Core I/O Models: From Blocking to Asynchronous

Introduction

First, we need to understand the I/O model by knowing which devices the underlying operating system uses for data transmission, then identify which operations involve blocking calls. With this basic knowledge, we can explore the evolution of I/O models and, finally, distinguish key terminology within these models. The following mind map outlines the topics to be shared.

Data Transmission Medium

The operating system uses hardware devices such as network interface controllers to transfer byte streams to the Internet, which are then routed to other computers based on IP addresses.

Unix Operating System Structure Diagram

Overview

User Space: Application programs run in user space and invoke kernel commands to read or write hardware devices.

System Kernel: Directly interacts with hardware; it acts as a mediator between user processes and the hardware.

Hardware: Network interface controllers transmit byte streams over the network to other systems.

File Descriptor (fd): In Linux/Unix, a process maintains a file descriptor table; the index in this array is the file descriptor used for I/O operations.

Thus, a user process cannot operate hardware directly; it must request the kernel, which then interacts with the hardware. Network data transfer across computers follows the path: user process → kernel → network interface controller → network → destination kernel → user process.

Network I/O Blocking Operations

Core Steps of an I/O Read Operation

The user process requests a data read from the kernel and must wait until the kernel obtains the data packet.

When the kernel has the data, it copies the packet from kernel space to user space.

I/O Blocking Operations

recvfrom is a system call that switches from user context to kernel context; the process remains blocked until the kernel finishes the operation.

select/poll allow a process to wait for any of multiple events; the kernel wakes the process when an event is ready or a timeout occurs.

Comparison of I/O Operations

recvfrom follows a 1:1 model: the kernel handles one request at a time, causing other requests to wait.

select/poll follow an N:1 model: the kernel monitors a set of descriptors, allowing many descriptors to be waited on simultaneously.

I/O Model Evolution

Network programming reads data that passes through the kernel before reaching user space. To simplify, UDP is used to illustrate five Unix I/O models.

Blocking I/O Model

The application calls recvfrom and blocks until the kernel copies the data to user space, unless interrupted.

Sequence diagram of blocking I/O.

Non‑Blocking I/O Model

When recvfrom is called and no data is available, the kernel returns an error indicating “no data yet, try later”.

The process repeatedly polls the kernel with recvfrom until data becomes available.

Once data is ready, the kernel copies it to the user buffer and returns success.

I/O Multiplexing Model

Uses select or poll to block on these functions rather than on the actual I/O call.

The process blocks in select until the kernel signals that a descriptor is readable.

When notified, the process calls recvfrom to copy data to user space.

Signal‑Driven I/O Model

Enable signal‑driven I/O on a socket and install a signal handler via sigaction . The call returns immediately.

The kernel sends a signal to the process when data arrives.

The handler then invokes recvfrom to copy the data.

Asynchronous I/O Model

Defined by the POSIX specification: the kernel performs the entire operation and notifies the process when it completes.

Unlike signal‑driven I/O, the kernel directly informs when the I/O is finished rather than just when it can be started.

Analysis of the Five I/O Models

Blocking I/O follows a 1:1 model; performance can be improved with multithreading to achieve an N:1 model similar to non‑blocking I/O.

Signal‑driven I/O is non‑blocking but involves complex kernel‑to‑user callbacks.

Non‑blocking I/O uses polling, which incurs kernel‑user context switches and reduces performance.

I/O multiplexing blocks in select , registers events, and waits for readability or timeout.

Asynchronous I/O (AIO) provides true non‑blocking behavior, though Linux/Unix support varies.

Most Unix/Linux servers are optimized around I/O multiplexing (enhanced select/poll ).

I/O Key Terminology

Definition of Synchronous and Asynchronous

Synchronous: The caller waits for the function to return a result or an exception; the operation is atomic.

Asynchronous: The caller returns immediately; the result is delivered later via callbacks or events.

Definition of Blocking and Non‑Blocking

Blocking: The thread waits (is suspended) until a resource becomes available.

Non‑Blocking: The thread proceeds without waiting; if the resource is unavailable, it receives an immediate indication.

Synchronous I/O vs Asynchronous I/O (POSIX)

Synchronous I/O: The process issues a real I/O request (e.g., recvfrom ) and blocks until the kernel completes it.

Asynchronous I/O: The process issues the request, the kernel returns an error indicating “not ready yet”, and later notifies the process when the operation finishes.

Blocking I/O: The kernel holds the process until the operation completes.

Non‑Blocking I/O: The kernel returns immediately, telling the process to try later.

I/O Model Comparison Diagram

According to the definitions, only the Asynchronous I/O model truly matches the POSIX asynchronous I/O specification; the other models involve recvfrom calls that block the kernel and are therefore synchronous I/O.