Deadlocks: The Dark Side of Concurrency
summary
Concurrent Go code from rclone produces real deadlocks involving mutexes and channels; the runtime detector rarely fires because some goroutines stay active. Diagnostics use SIGQUIT or net/http/pprof traces and collapse helpers like panicparse; static detectors like go deadlock catch many mutex-ordering issues. Concrete fixes include shortening lock windows, making fields immutable, offloading channel sends to new goroutines, and avoiding recursive RW locks — the ultimate invariant is enforcing total lock ordering or reverting to a single-threaded engine.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:54What is a deadlock?
- 5:04Simple deadlock
- 8:19Deadlock detector defeated
- 11:34File system example: in the beginning
- 12:46File system: locking needed in File
- 14:18File system: deadlock code
- 20:49HTTP debug handler output
- 24:44Channel deadlocks
- 30:00Read locks
- 36:55Total Lock ordering
- 40:54Go deadlock
related talks
41mDetecting and Fixing Unbound Concurrency Problems
26mConcurrency primitives of Golang - how to use and how not to
24mMastering Concurrency in Go: From Patterns to Production
27mProduction Ready Concurrency
01h 01mRoundtable: Concurrency
25mTackling Contention : The Monster in sync.Locker
28mEnd-to-end Deadlock Debugging Tools at Facebook
44mConcurrency in Go: from hardware to code ☠️