Learn the vocabulary of two threads each waiting forever on a lock the other one holds.
0 / 5 completed
1 / 5
At standup, a dev mentions thread A holding lock 1 while waiting on lock 2, and thread B holding lock 2 while waiting on lock 1, so neither thread ever makes progress again. What is this situation called?
A deadlock is exactly this: thread A holds lock 1 and waits on lock 2, while thread B holds lock 2 and waits on lock 1, so each is blocked forever on a resource the other refuses to release. A livelock is a related but distinct failure where threads keep responding to each other's state changes without ever actually blocking, yet still never progress. This circular-wait condition is the textbook definition of a deadlock, and it's why acquiring more than one lock at a time is inherently risky without a shared discipline.
2 / 5
During a design review, the team wants every thread in the codebase to acquire locks 1 and 2 in the same global order, never the reverse, specifically to make deadlock structurally impossible. Which capability supports this?
Enforcing a consistent global lock-acquisition order makes a circular wait structurally impossible, since if every thread always acquires lock 1 before lock 2, no thread can ever be found holding lock 2 while waiting on lock 1. Letting each thread pick its own order is exactly what allows two independently written code paths to deadlock the moment they happen to disagree. This ordering discipline is one of the standard, low-cost techniques for eliminating an entire category of deadlock by design rather than detecting it after the fact.
3 / 5
In a code review, a dev notices one function acquires lock A then lock B, while a different function elsewhere in the same module acquires lock B then lock A. What does this represent?
This is exactly a lock-ordering violation that risks a future deadlock, since if these two functions ever run concurrently and each grabs its first lock before the other releases theirs, both will block waiting on the other's second lock forever. A cache eviction policy is an unrelated concept about discarding cached data. This kind of reversed-order acquisition is precisely the subtle bug a reviewer needs to catch before two rarely-concurrent code paths happen to collide in production.
4 / 5
An incident report shows a production service hung completely, and a thread dump revealed two threads each waiting on a lock the other one held, because two independently written modules acquired the same pair of locks in opposite orders. What practice would prevent this?
Enforcing a single consistent lock-acquisition order across every code path removes the circular-wait condition a deadlock depends on, and a timed try-lock with backoff gives a thread a way to detect contention and retry instead of blocking forever if ordering slips through anyway. Continuing to let different code paths pick their own order is exactly what caused the hang described in this incident. This combination of ordering discipline and defensive timeouts is the standard defense once a deadlock has actually reached production.
5 / 5
During a PR review, a teammate asks why the team documents and enforces a global lock-acquisition order instead of trusting each module's author to simply avoid acquiring conflicting locks. What is the reasoning?
Two modules can each be perfectly correct on their own, yet still deadlock the instant they're combined if one happens to acquire lock A then B while the other acquires B then A, since neither author had visibility into the other's ordering choice. A documented global order removes that risk by construction, because no thread can ever hold the second lock in a pair while waiting on the first. The tradeoff is the ongoing discipline of actually following and reviewing for that documented order as the codebase grows and more modules start touching the same locks.
What does the "Deadlock Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to deadlock vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 9 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.