Identifying concurrency hazards in C++ mutex design
This easy concurrency question asks you to spot a common pitfall in how developers protect shared state with mutexes. Rather than write code from scratch, you are given a short snippet and asked to identify what kind of synchronization hazard it contains.
The question tests whether you can recognize the difference between correct locking discipline and code that appears to protect shared data but actually leaves a race condition or deadlock vulnerability. This matters in any system where multiple threads access the same resources—from trading engines to market data handlers.
- Mutex scope and lock duration
- Check-then-act patterns
- Thread-safety vs. atomicity
- Common locking anti-patterns