Thread Models and Reactor/Proactor Patterns in Server Architecture

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

Characteristics: uses blocking I/O to read input; each connection requires a dedicated thread for input, processing, and response.

Problems: high thread count under large concurrency consumes resources; threads block on read when no data, wasting resources.

2. Thread Model 2: Reactor Pattern

2.1 Basic Introduction

Reactor addresses the two drawbacks of blocking I/O by using I/O multiplexing and thread‑pool reuse, allowing many connections to share a single blocking object and dispatching ready events to worker threads.

Reactor is an event‑driven dispatch model where the server listens for events and forwards them to appropriate handlers.

Key components: Reactor (listens and dispatches) and Handlers (process I/O events).

Three typical implementations:

1) Single Reactor Single Thread 2) Single Reactor Multi‑Thread 3) Master‑Slave Reactor Multi‑Thread.

2.2 Single Reactor Single Thread

Explanation: Reactor uses Select to monitor client events, dispatches to Acceptor for new connections, creates a Handler for subsequent processing, and the Handler performs read → business logic → send.

Advantages: simple model, no thread‑communication issues.

Disadvantages: limited to one thread, cannot fully utilize multi‑core CPUs, may become a performance bottleneck.

Reliability issues: a runaway thread can render the whole communication module unavailable.

Use case: limited client count and fast O(1) business logic such as Redis.

2.3 Single Reactor Multi‑Thread

Explanation: Reactor monitors events, Acceptor handles new connections, creates Handlers; Handlers read data and hand off to a worker thread pool for business processing, then send responses back.

Advantages: leverages multi‑core CPUs.

Disadvantages: complexity of data sharing, Reactor can become a bottleneck.

2.4 Master‑Slave Reactor Multi‑Thread

Explanation: MainReactor handles accept events, distributes connections to SubReactors, each SubReactor creates Handlers and uses a worker pool for business logic, then sends responses.

Advantages: clear separation of responsibilities, easy data exchange between parent and child threads, widely used in Nginx, Memcached, Netty.

2.5 Summary

Analogy with restaurant staff illustrates the three models.

Reactor benefits: fast response, simple programming, scalability, reusability.

3. Thread Model 3: Proactor Model

Proactor moves I/O operations to the OS for asynchronous completion; after the OS finishes I/O, it notifies the application to process the result.

Key steps: Initiator creates Proactor and Handler, registers with AsyOptProcessor; AsyOptProcessor performs I/O; upon completion it notifies Proactor, which invokes appropriate Handler.

Differences from Reactor: Reactor notifies before I/O, application does synchronous read/write; Proactor performs I/O asynchronously in kernel, callback after completion.

Pros: higher efficiency, better DMA utilization.

Cons: programming complexity, memory usage, OS support limitations (Windows IOCP vs. Linux async I/O).

In Linux high‑concurrency networking, Reactor remains the primary model.