Synchronous vs Asynchronous I/O: Blocking, Non‑Blocking & Event‑Driven Models
This article explains the differences between synchronous and asynchronous I/O, clarifies blocking versus non‑blocking calls, and describes various I/O models—including blocking, non‑blocking, multiplexed, event‑driven, and asynchronous—illustrated with diagrams to help readers understand how the kernel and user processes interact during I/O operations.
I/O Types
Synchronous vs Asynchronous (synchronous, asynchronous): focusing on notification mechanism
Synchronous: After a process issues a system call, it does not receive an immediate response; when a response arrives, it is the final result.
Asynchronous: After a process issues a system call, it receives an immediate return that is not the final result; once the kernel finishes processing, it notifies the process that the call has completed.
Blocking vs Non‑Blocking (blocking, non‑blocking): focusing on the caller's state when the system call completes
Blocking: The caller remains suspended until the result is returned, then it can continue working.
Non‑Blocking: The caller is not suspended while waiting for the result; the system call itself does not block the caller.
I/O Model Classification
Blocking I/O
Non‑Blocking I/O
Multiplexed I/O
Event‑Driven I/O
Asynchronous I/O
Blocking I/O Model
When a user process initiates a system call, the process stays suspended until the kernel finishes the task (e.g., reading data from disk into kernel memory, processing it, and then transferring it to the process's memory). Only after this transfer can the process resume work.
Non‑Blocking I/O Model
After the system call, the process is not suspended; it repeatedly polls the kernel to check if the operation is complete. When the kernel finishes processing (data moved from disk to kernel memory), the process is briefly suspended while the kernel transfers the data to the process memory, after which the process can continue.
Multiplexed I/O Model
The process can issue multiple requests to the kernel; mechanisms such as select, poll, and epoll enable I/O multiplexing. Multiplexing allows a single process to monitor many descriptors and be notified when one becomes ready for reading or writing. Although select/poll/epoll are fundamentally synchronous (the process must perform the actual read/write after notification), asynchronous I/O offloads the data transfer from kernel to user space without the process’s involvement.
Event‑Driven I/O Model
When the process issues a system call, the kernel immediately returns a signal indicating receipt. The process can perform other work while the kernel prepares the data. Once ready, the kernel notifies the process, which is then suspended briefly to receive the data and can resume processing.
Asynchronous I/O Model
After the system call, the kernel returns a signal that the request has been received, allowing the process to continue other tasks. When the kernel finishes processing and transfers the data to the process memory, it notifies the process, which can then simply read the data and proceed.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
MaGe Linux Operations
Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
