The monsters inside the sync.Locker
summary
Explains that a Go mutex implements both read and write memory barriers by using atomic compare-and-swap and atomic add in the hot path, so locking guarantees visibility across caches; it spins with a spin-and-retry loop and falls back into starvation mode when contention persists, all implemented lock‑free and efficiently in the runtime. Recommends splitting state, keeping critical sections tiny, preferring mutexes over ad hoc atomics because atomics are easy to get wrong, and notes the race detector works with proper locks.
AI-written summary · about
chapters (6)
- 0:00Start
- 0:14What are Channels?
- 0:29Mutexes do two things
- 1:02A trip down memory lane
- 2:36Mutexes fast path
- 2:50Mutexes handle starvation
related talks
25mTackling Contention : The Monster in sync.Locker
26mTackling Contention: The Monsters Inside the 'sync.Locker'
43mDeep dive into the sync package
44mConcurrency in Go: from hardware to code ☠️
26mConcurrency primitives of Golang - how to use and how not to
52mSecrets of high performance in multicore systems ☠️
07mRace Conditions in Details
18mApplied concurrency in Go