How to build distributed concurrency primitives
summary
Shows that wrapping local locks in RPC breaks: killed lock holders never release locks. Demonstrates heartbeats plus monotonic fenced lock tokens so resources reject stale holders, and explains why single-node lock servers must replicate state with Raft consensus into a replicated state machine. Uses Hazelcast examples (AtomicLong, AtomicReference, Semaphore, CountDownLatch) and a demo where restarting the server creates two owners unless replicated. Notes performance tradeoffs: server-side alter function beats client read-modify-write and locking can be ~3x slower in tests.
AI-written summary · about
chapters (9)
- 0:00Introduction and background
- 11:25Naive distributed lock approach
- 13:58Heartbeat and lease problems
- 17:13Fenced lock concept
- 23:30Replicated log and consensus
- 37:03Hazelcast lock demonstration
- 37:28Avoiding locks when possible
- 43:42Key takeaways and summary
- 45:12Q&A session
related talks
45mjava.util.concurrent for Distributed Coordination
51mDo Not Reimplement Distributed Consensus Algorithms
47mjava.util.concurrent for Distributed Coordination
46mWhat can go wrong in a distributed system - experience from...
44mDistributed Locking in Kubernetes
47mDistributed Systems: When Democracy and Computer Science Come Together
41mWhat can go wrong with the distributed system - the Hazelcast exp...
01h 06mLocks are tricky — let's understand them by building one