Rusty lock

What this Rust concurrency and memory ordering question tests

This is a hard concurrency question that challenges your understanding of memory ordering guarantees in Rust and how they interact with spinlock semantics. It probes whether you can reason about the consequences of weakening memory barriers and predict which operations might escape a critical section.

The question focuses on the relationship between lock/unlock operations and the code they protect. A correct answer requires you to understand how different memory ordering modes (Acquire, Release, Relaxed) constrain reordering, and to identify which specific memory access—reading or writing—becomes vulnerable when a Release barrier is removed. This is the kind of subtle reasoning that surfaces bugs in concurrent systems and separates candidates who memorize APIs from those who understand the underlying guarantees.

• Acquire-Release semantics and their role in synchronisation
• Memory reordering and compiler/CPU instruction reordering
• Load and store atomicity in relation to critical sections
• Spinlock invariants and their enforcement through memory barriers