Learn the vocabulary of composing atomic memory updates that automatically retry on conflict instead of using explicit locks.
0 / 5 completed
1 / 5
A teammate describes a concurrency technique where a block of memory operations runs speculatively, and if another thread modified the same data concurrently, the whole block automatically retries instead of using explicit locks. What is this technique called?
Software transactional memory is exactly this: it lets a block of memory operations run speculatively as a transaction, and if a conflicting concurrent modification is detected, the transaction automatically aborts and retries, without the programmer writing explicit locks. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This speculative-retry-on-conflict approach is exactly why software transactional memory can replace manual locking for many composable concurrent operations.
2 / 5
During a design review, the team adopts software transactional memory for a bank account transfer routine, specifically so that transferring between two accounts either fully applies or automatically retries if another transaction conflicts, without deadlock-prone manual locks. Which capability does this provide?
Software transactional memory here provides composable, deadlock-free atomic updates, since transactions automatically retry on conflict instead of requiring the programmer to acquire multiple locks in a careful order to avoid deadlock. Manually acquiring two locks in whichever order the code happens to acquire them is exactly how classic lock-ordering deadlocks occur between concurrent transfers. This automatic-retry-on-conflict behavior is exactly why software transactional memory is favored for composing multiple atomic updates safely.
3 / 5
In a code review, a dev notices a fund-transfer routine acquires two separate account locks in an order that depends on which account object was allocated first, rather than running the transfer as a single software-transactional-memory transaction. What does this represent?
This is a missed software-transactional-memory opportunity, since running the transfer as a single transaction would let it automatically retry on conflict instead of risking a lock-ordering deadlock. A cache eviction policy is an unrelated concept about discarded cache entries. This allocation-order-locking pattern is exactly the kind of deadlock risk a reviewer flags once composable atomic updates are the goal.
4 / 5
An incident report shows two concurrent fund transfers deadlocked because each acquired one account's lock first and then blocked waiting for the other account's lock held by the other transfer. What practice would prevent this?
Rewriting the transfer as a software-transactional-memory transaction ensures a detected conflict causes an automatic retry instead of both transfers blocking on each other's locks. Continuing to acquire the two account locks in whichever order the transfer happens to encounter them regardless of how often deadlocks occur is exactly what caused the deadlock described in this incident. This retry-on-conflict approach is the standard fix once lock-ordering deadlocks are confirmed to occur between concurrent transfers.
5 / 5
During a PR review, a teammate asks why the team reaches for software transactional memory instead of fine-grained manual locking, given that manual locks are already well understood by the team. What is the reasoning?
Software transactional memory trades some runtime overhead for automatic conflict detection and retry, making composed atomic operations deadlock-free, while manual locking is familiar but requires careful lock ordering that becomes error-prone as more locks are composed. This is exactly why software transactional memory is favored when multiple atomic operations must be composed safely, while simple manual locking remains acceptable for a single, well-scoped critical section.
What does the "Software Transactional Memory Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to software transactional memory 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.