Chapter 14Concurrency Primitives MeasuredPaid chapter

sync Primitives — Mutex Modes, Pool Eviction, and Atomics

Understand the internal behavior of sync.Mutex, sync.Pool, sync.RWMutex, and sync/atomic — and when each is appropriate.

Launch paywall

This chapter is part of the paid launch. The preview stays visible so readers can evaluate the exact scope before buying.

Included in

Core and Complete. Complete also includes the practical exam and free Go-version updates.

Preview

What this chapter teaches

Common belief

RWMutex is faster for reads; sync.Map is the concurrent map; sync.Pool manages memory.

What actually happens

RWMutex only wins when reads heavily dominate; sync.Map loses to Mutex+map for write-heavy workloads; and sync.Pool can drop your objects at any GC — it reduces allocation rate, it does not guarantee retention.

Mechanisms covered

sync.Pool maintains per-P pools with a victim cache. Items survive at most two GC cycles. Pool is a performance optimization, never a correctness mechanism.

Atomic operations are lock-free on amd64 (LOCK XADD, LOCK CMPXCHG). Typed atomics (atomic.Int64 etc., Go 1.19+) prevent misuse/misalignment with identical codegen. sync.Once uses an atomic fast-path after first call.

benchexperiment

One-time purchase