An engineer proposes replacing locks in a hot code path with hand-written weakly ordered atomic operations and explicit memory fences for performance. As the technical decision-maker, how do you evaluate that proposal and what conditions would you attach?

## Framing: this is a risk purchase, not a code style choice Hand-rolled weak ordering buys throughput with a currency the team pays later: bugs that are undefined, intermittent, architecture-dependent, invisible to ordinary testing, and expensive to diagnose in production. The decision is whether the measured gain is worth that, and whether the risk can be contained. ## Axis 1 — Evidence that synchronization is the bottleneck Ask for a profile, not a belief. Uncontended lock acquisition is a cheap atomic operation; the costs people attribute to 'locks' are usually contention (threads serializing on shared state) or context switching. If contention is the cause, note that weakening ordering does not reduce contention at all — the same cache line is still bounced between cores. The cheaper interventions, in order: 1. **Share less.** Shard the structure, give each worker its own accumulator, merge at the end. 2. **Hold shorter.** Move I/O, allocation and formatting outside the critical section. 3. **Batch.** Amortize one synchronization over many items. 4. **Change the structure.** A queue handoff or single-owner design removes the sharing entirely. Only if those are exhausted, and a prototype shows a meaningful end-to-end win (not a microbenchmark delta), does the proposal stay alive. Amdahl's law is worth quoting here: if the synchronized section is 5% of the workload, perfecting it caps the gain at about 5%. ## Axis 2 — Containment Weak ordering must be an implementation detail. The rule I attach: it lives inside one small data structure or primitive with an ordinary, hard-to-misuse API, and no ordering obligation leaks to callers. If using the component correctly requires the caller to remember 'read this field only after that flag', the encapsulation has failed and the design should be rejected. Blast radius is what makes the difference between a bad week and a bad quarter. ## Axis 3 — Verification Testing cannot show the absence of a race, so verification must be structural: - **Race detectors** in CI, running the component's stress tests. - **Litmus-style tests** for the specific orderings the algorithm depends on. - **Both architecture classes.** A total-store-order machine forbids three of the four reorderings, so passing there proves nothing about weakly ordered targets. If the fleet is mixed — or might become mixed — test on both. - **Model checking or a published, peer-reviewed algorithm** for anything genuinely novel. 'We invented a lock-free structure' should raise the bar sharply; 'we implemented a well-known published algorithm faithfully' lowers it. ## Axis 4 — Maintainability and ownership Weakly ordered code is not self-documenting. Conditions I attach: each non-sequentially-consistent operation carries a comment stating the invariant it relies on and why the weaker tier is sufficient; the pairing partner of each release/acquire is named; and at least two engineers can explain the algorithm. Otherwise the first well-intentioned refactor — adding a field, reordering two lines, extracting a helper — silently deletes an ordering guarantee that no test will catch. Also consider organizational fit: a team that reviews this code twice a year will lose the knowledge. That argues for using a well-tested library primitive instead of owning the algorithm. ## Deciding Approve when: a profile shows real, dominating cost; the cheaper structural options are exhausted; the change is confined to one component with a safe API; a race detector and dual-architecture tests run in CI; and the ordering rationale is written down with named owners. Decline when the motivation is 'locks are slow' as a general belief, when the weak ordering would spread across call sites, when the fleet's target hardware cannot be tested, or when one person is the only reader of the algorithm. A good decision-maker also frames the reversal path: if this becomes a maintenance problem, what does going back to a lock cost? If the answer is 'a one-line change inside one file', the risk is bounded and the experiment is reasonable. If the answer is 'a redesign', it is not. ## What interviewers are listening for Not an opinion about locks. They want measurement before optimization, containment of dangerous techniques, an honest statement that testing cannot prove concurrency correctness, an awareness of architecture portability, and attention to who maintains it after the author leaves.