Build fluency in the vocabulary of two concurrent operations silently corrupting shared state.
0 / 5 completed
1 / 5
At standup, a dev mentions two requests reading a counter's current value, each incrementing it locally, and each writing back, so one of the two increments is silently lost because neither read saw the other's write. What is this bug called?
A race condition happens exactly here: two requests each read the same counter value, increment their own local copy, and write back, and whichever write happens second simply overwrites the first, silently losing one of the two increments. A deadlock is a different failure mode entirely, where threads are blocked rather than corrupting shared state. This kind of lost update is one of the most common race conditions in any system where more than one process reads, modifies, and writes back shared state without coordination.
2 / 5
During a design review, the team wants the counter increment to happen as a single atomic read-modify-write operation, so no other request can read a stale value in between. Which capability supports this?
An atomic increment operation, or a compare-and-swap loop that retries if the value changed underneath it, combines the read and the write into a single indivisible step, so no other request can slip in a conflicting read between them. Continuing to read, increment, and write as three separate steps is exactly the pattern that allows two concurrent requests to interleave and lose an update. This atomicity is the standard fix for a race condition on a single shared value like a counter.
3 / 5
In a code review, a dev notices a function checks whether a file exists and then, in a separate later step, opens it, with another process able to run in between those two steps. What does this represent?
This is a classic time-of-check to time-of-use (TOCTOU) race condition, since the file's state can change in the gap between the existence check and the later open, for instance if another process deletes or replaces it in between. A cache eviction policy is an unrelated concept about discarded cache entries. This TOCTOU pattern is a well-known category of race condition that shows up whenever a check and its corresponding action aren't performed as a single atomic step.
4 / 5
An incident report shows two concurrent checkout requests both read a product's stock as one unit remaining and both proceeded to complete the sale, resulting in the same last unit being sold twice, because the stock check and the decrement weren't combined into one atomic operation. What practice would prevent this?
Performing the stock check and the decrement as a single atomic operation, such as a conditional update that only succeeds if the stock is still at least one, closes the gap where two concurrent requests could both read the same value before either one writes. Continuing to treat the check and the decrement as separate steps is exactly what allowed the same last unit to be oversold in this incident. This atomic check-and-decrement pattern is the standard fix for a race condition on any resource with limited availability.
5 / 5
During a PR review, a teammate asks why the team wraps a shared counter's read-modify-write sequence in an atomic operation instead of just trusting that two requests are unlikely to arrive at nearly the same moment. What is the reasoning?
Under real production load, two requests arriving close enough together to interleave stops being a rare edge case and becomes a routine occurrence, since higher concurrency directly increases the odds of two operations overlapping in exactly the vulnerable window. An atomic operation removes the possibility of a lost update entirely, regardless of how much concurrent traffic the system sees. The tradeoff is the added complexity, and sometimes contention overhead, of wrapping every shared-state update in an atomic primitive instead of writing the simpler, unsafe three-step version.
What does the "Race Condition Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to race condition 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 — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
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.