You are designing a heavily read, occasionally updated shared index in a systems language with manual memory management, and must pick a memory-reclamation strategy for it: hazard pointers, an epoch-based scheme, a read-copy-update style grace period, or avoiding the problem entirely. How do you decide, and what would make you reject the lock-free design altogether?

## Frame the decision, not the algorithm At this level the interesting question is not which scheme is cleverest but which failure mode you can live with. All three candidate schemes are correct; they differ in cost distribution and in how they degrade. ## Axis 1 — bounded memory versus cheap reads This is the central trade. **Hazard pointers** make every protected pointer traversal do work: store the pointer into a per-thread slot, fence, re-validate that the pointer is still installed, and only then dereference. In exchange, the set of nodes that cannot be freed is bounded by threads times slots, plus whatever is sitting in the retire batch. Memory is predictable under every schedule. **Epoch-based reclamation** costs one publish at region entry and nothing per pointer, so read-heavy traversals run at close to unsynchronised speed. Its liveness condition is that every thread eventually leaves its critical region. If one does not — preemption on an oversubscribed box, a page fault, a blocking syscall someone added inside the region — the epoch cannot advance, and *every* retired node in the system stays unfreed. The structure remains correct while the process runs out of memory. **Read-copy-update style grace periods** are epoch-based reclamation with a different quiescence detector. In a kernel, quiescence can be inferred from context switches, making the read side literally free. In user space you need an explicit mechanism, and the same stalled-reader exposure applies. So: **can a read-side critical region stall?** If yes and unboundedly, take the bound. If read sections are short, non-blocking, non-preemptible, or bounded by design, take the cheap reads. ## Axis 2 — the shape of the workload Count pointer dereferences per read. A hash table with a one-hop lookup pays hazard-pointer overhead once per operation — tolerable. A skip list or tree traversal touching a dozen nodes pays it a dozen times, and the fences alone can dominate. Symmetrically, count retirements per second: epoch schemes accumulate garbage proportional to retire rate times stall duration, so a low-update index tolerates a long stall while a churny one does not. Also ask whether reclamation can be *amortised elsewhere*: batching retires, reclaiming on a dedicated thread, or piggybacking on an existing periodic maintenance pass all change the arithmetic more than the choice of scheme does. ## Axis 3 — blast radius and operability These bugs do not fail gracefully. A reclamation error is memory corruption with a delayed, misattributed symptom, and it is schedule-dependent, so ordinary tests miss it. Before approving a hand-rolled design I want: stress tests that deliberately inject stalls and preemptions inside read regions; sanitiser and race-detector runs in CI; a model-checked or exhaustively-interleaved harness for the small core; an exported metric for deferred-list length with an alert; and a named owner. If the organisation cannot fund that, the design is wrong regardless of which scheme is technically best. ## Axis 4 — avoid the problem The strongest principal-level answer usually starts by trying not to need reclamation at all: - **Never free.** If the index is append-mostly or bounded, retiring into an arena freed at a safe point (end of request, end of epoch of the whole process, structure rebuild) removes the entire question. - **Partition.** Shard the index so each thread owns a slice, converting shared mutation into local mutation plus message passing. No shared removal, no reclamation problem. - **Copy-on-write whole snapshots.** For small or rarely-updated indexes, publishing a whole new immutable snapshot and retiring the old one reduces reclamation to one object with a single lifetime rather than per-node bookkeeping. - **Just take a lock.** A reader-writer lock or a sharded lock with short critical sections often meets the target and is understood by everyone on the team. Lock-free buys worst-case progress under preemption — if that is not a requirement you actually have, you are paying a large complexity premium for nothing. - **Use a vetted implementation.** Reclamation schemes are library-grade code. Writing your own is justified only when profiling shows the shared structure is the bottleneck and no existing implementation fits. ## The answer in one shape State the trade (bounded memory versus cheap reads), map it onto whether your readers can stall and whether your memory is capped, size it against the read profile, then say what you would demand operationally — and be explicit that the default recommendation is to avoid hand-rolled lock-free reclamation unless a measured bottleneck justifies it.