Mastering Asynchronous Programming: From Sync/Async Basics to I/O Models

1. Asynchronous Programming

[1] Synchronous and asynchronous describe the way processes/threads are invoked

Synchronous and Asynchronous

Synchronous call means the thread waits for the call to return before proceeding; the CPU also waits, and the OS may switch to another thread during this time.

Asynchronous is the opposite: after initiating a call, the thread continues execution and is notified later when the call completes.

Explanation

In both sync and async, the return of the call involves the kernel copying data to the calling process. In sequential programming, calls are usually synchronous, executing the next step only after the previous one finishes. In async programming, when a waiting operation occurs, execution continues until the request returns, then processing occurs.

When crawling websites with multithreading or multiprocessing, slow network requests cause threads to wait idly, even if a timeout is set.

Asynchronous programming suits such scenarios by switching tasks to minimize idle time: if a request is waiting, the program skips it and processes the next one, returning later when ready.

[2] Synchronous and asynchronous programming model explanation with diagrams

Single‑threaded synchronous model

Only one task runs at a time; the next task starts after the previous one finishes. If tasks follow a predetermined order, the completion of the last task means all tasks are done.

Multithreaded/Multiprocess synchronous model

Each task runs in its own thread/process, managed by the OS. On multi‑core CPUs they may run independently; on single‑core they are interleaved.

Asynchronous programming model

The task is interleaved under single‑thread control, simpler than multithreading because there is no content copying or resource passing, and the program retains full control.

Developers organize tasks into a sequence of small steps; each async call must be short and non‑blocking.

While the model reduces context‑switch overhead, its advantages appear when tasks involve forced waiting or blocking I/O.

Blocking and non‑blocking refer to I/O states. When a thread/process calls a function that must wait for I/O, the OS blocks it to avoid wasting CPU. After completion, it becomes ready again. Blocking is not equivalent to synchronous, and non‑blocking is not equivalent to asynchronous.

2. I/O Programming Model

This model addresses the slowness of I/O; understanding it helps write asynchronous non‑blocking code.

What is an I/O model?

When I/O occurs (e.g., network read), two objects are involved: the calling process/thread and the kernel. First, data is prepared (disk to kernel memory); second, data is copied from kernel to process memory.

In Python, the first stage is data preparation, the second is returning the result.

[1] Blocking I/O model

Both stages keep the application process blocked, consuming CPU resources.

[2] Non‑blocking I/O model

The application repeatedly polls to see if the first stage is complete. It avoids blocking but may busy‑wait, so it is not always better.

[3] Multiplexed I/O model

A proxy (select/poll) sits between the application and kernel, handling all requests while the application waits for results.

Even with a proxy, the model remains blocking because the proxy itself can block, though it can still accept other requests.

[4] Signal‑driven I/O model

The application notifies the kernel to load data; the kernel signals completion, allowing the process to handle other requests without blocking on the proxy.

Performance may still be limited because the second stage remains blocking.

[5] Asynchronous I/O model

All other models are synchronous; this confirms that blocking ≠ synchronous and non‑blocking ≠ asynchronous.

The application notifies the kernel, which completes both stages silently and then notifies the process—truly non‑blocking and capable of handling many requests with high performance.

Level‑triggered: the kernel repeatedly notifies until the application processes the event, consuming resources.

Edge‑triggered: the kernel notifies once; if not processed, the event is stored for later handling, which is more efficient.

3. Event‑Driven

These scenarios often appear in C/S models on busy server sides

Use cases for async models

Large numbers of tasks ensure at least one runs at any time.

Tasks perform extensive I/O; synchronous models would block and waste CPU.

Tasks are largely independent with minimal internal interaction.

Event‑driven models trigger operations via events

Event‑driven model

Common in GUIs, network services, and web front‑ends. For example, each button in a GUI has a listener that runs only when the button is clicked.

Programs have a main loop (event loop) that continuously monitors for events and dispatches them to handlers; the loop runs in a single thread.

Python 2 async frameworks include Tornado (event loop), Twisted (event‑driven network engine), and Gevent (coroutine‑based). Python 3.6+ includes asyncio in the standard library.