A distributed-systems veteran wrestles with McKenney's parallel programming bible

This is a personal review of Paul E. McKenney’s free online textbook “Is Parallel Programming Hard, And, If So, What Can You Do About It?” — McKenney being the author of the Linux kernel’s RCU synchronization mechanism. The reviewer arrives from a decade in TLA⁺ and distributed systems, looking to pivot toward low-level, lock-free concurrency after a conference conversation with Filip Pizlo convinced him he understood far less about actual multicore behavior than he’d assumed. He chose McKenney’s book for its focus on general concurrent programming and CPU cache effects rather than narrower treatments of lock-free data structures.

The technical takeaways center on how real hardware breaks naive mental models. Chapter 3 walks through CPU cache behavior, and the reviewer flags a real gap: the MESI cache-coherence protocol — key to understanding how cores mediate concurrent reads and writes — is buried in an appendix despite being essential context. A concrete insight he draws out is that truly simultaneous writes to the same address don’t happen on x86: a core must hold exclusive ownership of a cache line to write, so competing writes serialize (though writes spanning two cache lines can still tear). Chapter 4 details the ways compilers and CPUs sabotage careless parallel code — load/store tearing and fusing, invented loads and stores, reordering, and dead-code elimination — reinforcing why lock-free programming is treacherous compared to mutexes or message passing.

The main criticisms are practical rather than fundamental. The book is heavily oriented toward Linux kernel idioms (ACCESS_ONCE, WRITE_ONCE, volatile casts) and skips the formal memory model work done in C11 and C++11, such as std::memory_order, which the reviewer wanted covered in depth. He also gripes about the reading experience: the PDF is riddled with internal links that make it nearly unusable on a touchscreen e-reader without page-turn buttons. The verdict is broadly positive — the material hit his level well — but he suggests the book assumes a hardware foundation it should teach more directly.