Hard Runtime Diagnostics interview problem
Coarse lock convoy in shared registry
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
A feature-flag registry is correct on one thread but stops scaling when readers arrive concurrently. CPU remains low while latency tracks an expensive cache rebuild instead of a cheap lookup.
This is a hard production-debugging exercise because reducing lock scope must preserve single rebuild, safe publication, and consistent snapshots without introducing a race. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
Callers read an immutable derived view of targeting rules. Invalidation should cause exactly one rebuild, and ordinary readers should proceed together while always observing a complete, internally consistent generation.
One coarse exclusive lock covers both the common read path and the rare rebuild. Readers form a convoy behind the slow critical section, and adding worker threads increases waiting rather than throughput.
What you’ll practice
- Recognizing a lock convoy in thread-dump evidence
- Separating read concurrency from rebuild coordination
- Publishing immutable snapshots safely
- Preventing duplicate rebuild work after invalidation
- Measuring reader overlap instead of relying on elapsed time alone
How to approach it
Map each blocked stack to the critical section it wants, then compare lock hold time for lookup and rebuild. The common reader path should not inherit the cost profile of cache construction.
Design around immutable generations: coordinate who builds, then publish a complete view atomically. Stress simultaneous readers immediately after invalidation to verify both concurrency and exactly-one rebuild.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Coarse lock convoy in shared registry?
Begin with thread dumps, lock ownership and wait states, reader overlap metrics, rebuild counts, and derived-view checksums. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard runtime diagnostics problem?
It is hard because reducing lock scope must preserve single rebuild, safe publication, and consistent snapshots without introducing a race. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.