Deep dive into the sync package
summary
Shows how core sync types are implemented: WaitGroup stores an atomic state plus a semaphore and releases the semaphore once per waiter, Mutex stores bits for woken and starving plus a waiter count and switches fairness, Once uses an atomic bool fast path with a mutex slow path, sync.Map uses a read and dirty maps design with a miss counter that promotes dirty into read, sync.Pool keeps per-P local and victim pools so objects can survive one GC cycle, and Cond unlocks the mutex inside Wait.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:30Why sync matters in Go
- 2:13Atomic operations
- 5:14Semaphores for goroutines
- 7:39Understanding WaitGroup in depth
- 12:18Mutex internals
- 16:15How sync.Once ensures single execution
- 20:07sync.Map for concurrency
- 26:31sync.Pool for objects
- 31:52sync.Cond’s quirks
- 37:27Summary of sync primitives
- 38:31Q&A
related talks
04mThe monsters inside the sync.Locker
29mGo Sync or Go Home
12mSwimming pool semaphores
26mTackling Contention: The Monsters Inside the 'sync.Locker'
25mTackling Contention : The Monster in sync.Locker
01h 07mThe C++20 Synchronization Library
26mConcurrency primitives of Golang - how to use and how not to
01h 00mConcurrency in C++20: A Deep Dive