Understanding Thread Models in High‑Performance Network Programming

1. Thread Model 1: Traditional Blocking I/O Service Model

The blocking I/O model assigns a dedicated thread to each connection for reading, processing, and responding, which leads to high resource consumption and thread waste when many connections are idle.

2. Thread Model 2: Reactor Pattern

2.1 Basic Introduction

Reactor combines I/O multiplexing with a thread‑pool to allow many connections to share a single blocking object, reducing thread count and improving scalability.

2.2 Single Reactor Single Thread

A single thread runs the Reactor, handling all events sequentially; while simple and free of concurrency issues, it cannot fully exploit multi‑core CPUs and becomes a bottleneck under load.

2.3 Single Reactor Multi‑Thread

The Reactor still listens for events in one thread, but dispatches request handling to a worker thread pool, enabling better CPU utilization at the cost of more complex data sharing and potential bottlenecks in the Reactor itself.

2.4 Master‑Slave Reactor Multi‑Thread

A main Reactor accepts new connections and distributes them to multiple sub‑Reactors, each with its own handler and worker pool; this separates connection acceptance from processing, improving scalability and simplifying data exchange.

2.5 Summary of Reactor Variants

The three models can be likened to restaurant staff: a single staff member handles both greeting and service, multiple staff share greeting and service roles, or multiple greeters and servers work together, each offering different performance trade‑offs.

3. Thread Model 3: Proactor Model

Unlike Reactor, Proactor delegates the actual I/O operation to the operating system via asynchronous I/O; the application is notified only after the I/O completes, which can yield higher efficiency but introduces greater programming complexity, higher memory usage, and limited OS support.

In practice, Linux high‑concurrency servers usually prefer the Reactor model, while Windows can leverage IOCP‑based Proactor implementations.

For further reading, the author references an e‑book titled "IO Knowledge and System Performance Deep Tuning (2nd Edition)" that expands on performance evaluation challenges.