RaceConditions Deadlocks
Race conditions (outcome depends on timing) and deadlocks (two operations wait on each other forever) are the correctness bugs concurrency introduces.
Why we need this / what value this brings
These bugs are notoriously hard to reproduce (timing-dependent) and can cause silent data corruption (race) or a fully hung process (deadlock) in production.
When to use this
Whenever introducing any lock or any shared mutable state accessed concurrently — reason about these failure modes at design time, not after a bug report.
How to use or implement this
For races: identify the shared state and protect it with the narrowest lock that covers it. For deadlocks: always acquire multiple locks in the same, consistent order everywhere in the codebase.
Research questions
- Has the booking-slot-decrement logic ever been stress-tested for a race between two simultaneous bookings for the last available slot?
Empty folder — drop notes, links, and findings here as you research.