Why ‘Share Nothing’ Should Be the Default Concurrency Model for Modern Servers

Overview

The “share‑nothing” principle—originating from Go’s concurrency model and enforced by PHP’s parallel extension—advocates that threads should not share mutable memory. Instead, communication must occur through explicit message passing (e.g., unbuffered channels). The article examines why this model is not the default in many languages despite modern hardware capabilities.

Historical Context of SMP and POSIX Threads

Early symmetric multiprocessing (SMP) systems such as the 1989 Compaq SystemPro used dual 33 MHz Intel 386/486 CPUs with only 4–32 MB of RAM. At that time the POSIX threads API (standardized in 1995) was designed for lightweight threads that shared an address space because the hardware could not afford heavyweight isolation.

By the mid‑2000s, mainstream CPUs (e.g., Intel Core 2 Duo, ~1.8 GHz, multiple GB RAM, dual cores) made the original constraints obsolete. The article asks whether a 12‑year‑old API would still choose shared‑address‑space concurrency on today’s machines.

Share‑Nothing in PHP

PHP’s traditional “share‑nothing” architecture isolates each interpreter instance, mirroring the CGI model. Early attempts to add threading (the pthreads extension, released in 2012) had to respect this isolation, so true shared memory was impossible without breaking invariants. Although pthreads demonstrated that PHP can run threaded code, its API was awkward because it suggested shared memory while actually providing none.

Execution Models

Synchronous execution : tasks run sequentially on a single thread.

Asynchronous execution : tasks interleave cooperatively on a single thread (event‑loop style).

Parallel execution : tasks run concurrently on separate OS threads.

The parallel Extension (2019)

Learning from pthreads, the author created the parallel extension, which implements a CSP‑style channel API similar to Go’s. Threads can only read data from another thread via exclusive, unbuffered channel reads, eliminating mutable shared state.

Do not communicate by sharing memory; instead, share memory by communicating.

Consequences of this design:

No race conditions (no mutable shared state).

No deadlocks caused by lock ordering (no locks).

No memory corruption (isolated address spaces).

No data races (all communication is explicit).

Correctness is guaranteed by construction rather than by programmer discipline.

Interaction with PHP OpCache and Immutable Symbols

PHP’s APC/OpCache has long shared compiled code across requests, but historically each request copied symbols into request‑local memory, incurring duplication overhead. Starting with PHP 7.4, Zend introduced immutable symbols, allowing code to execute directly from shared memory without per‑request copying.

The parallel extension leverages this feature: when OpCache is present, it reads immutable code from the shared cache; when OpCache is absent, it still provides immutable symbols, avoiding the costly copy of the entire symbol table for each thread.

Implications and Future Direction

For three decades, concurrency education has centered on mutexes, locks, and critical sections—mental models tied to 1995 hardware limits. Modern multi‑core, high‑memory servers can safely adopt a share‑nothing default, reducing bugs and improving productivity.

The parallel extension embodies this shift, offering a safe, efficient API that matches current hardware realities.

Documentation: https://php.net/parallel