Memory Barriers & Visibility
debt(d9/e7/b5/t7)
Closest to 'silent in production until users hit it' (d9). The term's metadata explicitly states detection_hints automated: no, and why_it_matters notes these bugs 'work in testing (single-threaded) but fail intermittently under multi-threaded load.' No tooling catches this; it surfaces only under concurrent production load.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix requires switching to Swoole Channels for inter-coroutine communication and replacing shared mutable state with Redis/DB for inter-process communication. This is not a single-line fix — it touches every place shared mutable state is used across coroutines, which is inherently cross-cutting in a Swoole application.
Closest to 'persistent productivity tax' (b5). Applies to cli and queue-worker contexts (not universal), but within those contexts every coroutine-based design decision must account for visibility rules. The misconception is widespread, meaning the burden is ongoing: every new developer working in Swoole must learn and apply these constraints, slowing many work streams.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception is that PHP developers don't need to worry about memory barriers at all — which is true for PHP-FPM but fatally wrong for Swoole/extension authors. A competent developer familiar with PHP-FPM will carry that assumption into Swoole and assume shared variables are always visible to other coroutines, leading to hard-to-reproduce bugs.
TL;DR
Explanation
CPUs and compilers reorder instructions for performance. Without barriers: thread A writes X then Y, but thread B sees Y updated before X. Memory barrier forces: (1) all writes before the barrier are visible before writes after it, (2) all reads after the barrier see writes before it. Java volatile, C++ std::atomic — add barriers implicitly. In PHP: not exposed at language level — each request has its own memory space. In multi-threaded Swoole/pthreads: memory visibility is a concern. Relevant for PHP developers: understanding why Redis/DB is needed for inter-process communication (processes don't share memory, ensuring visibility).
Common Misconception
Why It Matters
Common Mistakes
- Assuming shared variables in Swoole are always visible to other coroutines.
- Not using channels for inter-coroutine communication.
Code Examples
// In Swoole — no barrier between coroutines:
$shared = false;
go(function() use (&$shared) { $shared = true; });
go(function() use (&$shared) {
// May see $shared as false — no memory barrier
if ($shared) doWork();
});// Use Swoole Channel for visibility guarantee:
$chan = new Swoole\Coroutine\Channel(1);
go(function() use ($chan) { $chan->push(true); });
go(function() use ($chan) {
if ($chan->pop()) doWork(); // Guaranteed visible
});