Build fluency in the vocabulary of an instruction that stops the CPU and compiler from reordering memory operations.
0 / 5 completed
1 / 5
At standup, a dev mentions an instruction that prevents the CPU and compiler from reordering memory reads and writes across it, so every operation before the instruction is guaranteed to complete, and be visible to other threads, before any operation after it begins. What is this instruction called?
A memory barrier, also called a memory fence, is exactly this: an instruction that prevents the CPU and compiler from reordering memory reads and writes across it, guaranteeing every memory operation issued before the barrier completes and becomes visible to other threads before any memory operation issued after the barrier begins. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This reordering-prevention guarantee is exactly what makes concurrent code correct on hardware and compilers that are otherwise free to reorder memory operations for performance.
2 / 5
During a design review, the team places a memory barrier between writing a shared data structure's contents and setting a flag that announces the structure is ready, specifically so another thread can never observe the flag set before the data it points to is fully written. Which capability does this provide?
This memory barrier provides a guaranteed visibility order across threads, ensuring the data is always fully written and visible to other threads before the ready flag can ever be observed as set, since the barrier prevents the CPU or compiler from reordering the flag's write ahead of the data's write. Omitting the barrier would leave that ordering unguaranteed on hardware and compilers that are otherwise free to reorder memory operations for performance, risking another thread seeing the flag set while the data behind it is still only partially written. This enforced ordering is exactly why a memory barrier is essential for this kind of ready-flag pattern in concurrent code.
3 / 5
In a code review, a dev notices a piece of concurrent code writes a shared structure's data and then sets a flag announcing it's ready, with no memory barrier at all between the two writes, on a platform known to allow memory reordering. What does this represent?
This is a missing memory barrier, since without one, a platform known to allow memory reordering can let another thread observe the ready flag set before the data write it's supposed to guard has actually become visible, letting that thread read a structure that looks ready but is still only partially written. A cache eviction policy is an unrelated concept about discarded cache entries. This missing-barrier pattern is exactly the kind of subtle, hardware-dependent concurrency bug a reviewer familiar with memory ordering would flag, since it can work fine on one platform and fail unpredictably on another.
4 / 5
An incident report shows a consumer thread occasionally read a shared structure with garbage or partially-written data, even though a producer thread always wrote the data fully before setting a ready flag, because there was no memory barrier between those two writes on a platform that allows memory reordering. What practice would prevent this?
Inserting a memory barrier between the data write and the ready-flag write guarantees the data is fully written and visible to other threads before the flag can ever be observed as set, which is exactly the fix for the garbage-data reads described in this incident. Continuing to write the data and the flag with no barrier between them regardless of the platform's reordering behavior is exactly what let the consumer occasionally observe the flag before the data was actually ready. This memory-barrier fix is the standard, well-understood remedy for exactly this class of ready-flag visibility bug on hardware that permits memory reordering.
5 / 5
During a PR review, a teammate asks why the team inserts an explicit memory barrier here instead of just trusting that writing the data before the flag in the source code guarantees the same order in memory. What is the reasoning?
Both the CPU and the compiler are free to reorder memory operations that have no observable data dependency between them, purely to improve performance, so writing the data before the flag in the source code doesn't by itself guarantee that same order becomes visible to another thread reading through main memory. An explicit memory barrier is what actually enforces that ordering at both the compiler and hardware level, closing the gap between what the source code says and what another thread might actually observe. The tradeoff is the barrier's own small performance cost, which is a necessary price for correctness whenever one thread's write ordering needs to be reliably visible to another thread.