Learn the vocabulary of an atomic instruction that only writes a new value if it still matches what's expected.
0 / 5 completed
1 / 5
At standup, a dev mentions a single atomic CPU instruction that reads a memory location, compares it to an expected value, and only writes a new value if the two still match, all as one indivisible step. What is this instruction called?
Compare-and-swap, or CAS, is exactly this single atomic instruction: it reads a memory location, compares it to an expected value, and only writes a new value if the two still match, with the whole read-compare-write sequence happening as one indivisible step that no other thread can interrupt partway through. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This atomic read-compare-write behavior is exactly what lets concurrent code update shared memory safely without ever needing a traditional lock.
2 / 5
During a design review, the team builds a lock-free counter using compare-and-swap in a retry loop, reading the current value, computing the new value, and calling CAS, retrying from the start whenever another thread's CAS wins the race first. Which capability does this retry loop provide?
This retry loop provides correctness under concurrent updates without ever blocking a thread with a traditional lock, since if another thread's compare-and-swap wins the race and changes the value first, this thread's own CAS simply fails, and it retries by rereading the now-current value and computing again, rather than corrupting the counter or requiring a lock at all. Simply writing the new value directly with no comparison would let two threads silently overwrite each other's updates. This detect-and-retry behavior is exactly what makes CAS the foundation of lock-free data structures.
3 / 5
In a code review, a dev notices a shared counter is updated by reading its current value, computing an incremented value, and writing it back directly with no atomic compare-and-swap step protecting the write. What does this represent?
This is a race condition, since without an atomic compare-and-swap step, two threads can both read the exact same current value, both independently compute the same incremented value, and then one thread's write can silently overwrite the other's, meaning one of the two increments is lost entirely even though both threads believed they succeeded. A cache eviction policy is an unrelated concept about discarded cache entries. This unprotected read-then-write pattern is exactly the kind of concurrency bug a compare-and-swap-based update, retrying whenever the value has changed underneath it, is designed to prevent.
4 / 5
An incident report shows a shared request counter under-reported traffic in production, because it was updated by reading the current value, incrementing it, and writing it back directly with no atomic protection, letting concurrent updates silently overwrite each other. What practice would prevent this?
Updating the counter with a compare-and-swap loop, so a losing update simply rereads the now-current value and retries instead of silently overwriting another thread's increment, guarantees no update is ever lost, which is exactly the fix for the under-reporting described in this incident. Continuing to read, increment, and write the counter back directly with no atomic protection is exactly what let concurrent updates silently clobber each other. This detect-and-retry pattern, built on compare-and-swap, is the standard, lock-free fix for exactly this class of lost-update race condition.
5 / 5
During a PR review, a teammate asks why the team reaches for a compare-and-swap retry loop instead of just protecting the counter update with a traditional lock, given that both approaches prevent the same lost-update race condition. What is the reasoning?
A compare-and-swap loop avoids ever blocking a thread outright, since a losing attempt just retries immediately with a fresh read instead of putting the thread to sleep the way a traditional lock does under contention, which can scale better when many threads are updating the same value concurrently. The tradeoff is that the update has to be structured as a retryable read-compute-write step, which is straightforward for something like a counter but can get considerably more intricate for a more complex shared structure. This is exactly why compare-and-swap is favored for simple, hot, frequently-contended updates, while a traditional lock remains simpler to reason about for more complex critical sections.