Avoiding Conflicts in Highly-Concurrent Applications
summary
Describes three concrete techniques—atomic ops, snapshot reads, versionstamps—and applies them to a sync queue that must append and let multiple readers pop. Naive max_token increments cause frequent commit conflicts and lost inserts under concurrency; adding randomness plus snapshot reads reduces conflicts but still loses items. Replacing keys with commit-ordered versionstamps yields blind appends with zero conflicts and unlimited parallelism but increases key size (≈12 bytes), is non‑idempotent, and complicates deletes/updates and client bookkeeping.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 0:48What is a conflict
- 2:24Outline
- 2:40Atomic Operations
- 3:51Snapshot Reads
- 5:18Version Stamps
- 6:29Case Study Sync
- 7:08Simple Approach
- 8:51LowConcurrency
- 10:02Max Atomic
- 11:43The Deeper Problem
- 14:06Version Stamp Operations
- 15:40Problems with Version Stamp Operations
- 17:17Conclusion
related talks
45mTransactions and Concurrency Control Patterns
17mJust-Right Consistency
41mConcurrency, Scalability and Transactions -- Myths and Surprises
19mBuilding a Performant Configuration-Store Layer
41mTransactions: myths, surprises and opportunities
51mHigh-concurrency distributed snapshots
28mData corrupting architectures we know and love
35mDon't Give Up on Serializability Just Yet