Hazard pointers and epoch reclamation

A hazard-protected reader first obtains a candidate pointer from the shared source, publishes that candidate in its hazard record, and rereads the source. If the source changed, it retries before dereferencing the candidate. The validation closes the window in which the candidate could have been removed before the reader announced protection. If validation succeeds under the chosen protocol, the reader may inspect the object while keeping its protection active. Clearing the record ends that permission; retaining a raw pointer after clearing it defeats the protocol.

The order of these actions is a memory-model requirement, not merely the order in which lines appear in source code. Publication, validation, and a reclaimer’s scan require the barriers or atomic orderings prescribed by a proven implementation. Do not replace them with relaxed atomics because a stress test passed. A hazard record also protects an object lifetime, not arbitrary concurrent writes to its fields. Those fields need immutability, atomic access, or another synchronization mechanism. Preventing use-after-free and preventing data races are different achievements.

After unlinking an object, an updater retires it into a deferred list. A hazard scan collects the currently protected addresses and reclaims eligible retired objects that are absent, following the protocol’s ordering and ownership rules. Batching amortizes scans, but retains memory longer. A thread paused with two valid hazard records can pin those particular objects; that does not mean it pins every object retired afterward. Bounds on total retained storage still depend on retirement thresholds, registration policy, and the particular algorithm. Preventing unsafe address reuse does not rule out every logical ABA transition; the surrounding algorithm still needs its own state-change argument.

Epoch-based reclamation typically brackets operations with an active interval and an announced epoch. A retired object remains unavailable for reuse until the scheme establishes that participants which could hold its old references have passed a quiescent state or otherwise advanced safely. Exact advancement rules differ across implementations. A stalled active participant can prevent reclamation of a growing set of later retired objects. This is why a lock-free data structure does not automatically provide a nonblocking or bounded-memory reclamation system under arbitrary thread suspension.

Hazard pointers suit explicit protection of a small number of nodes and can tolerate delayed threads while limiting which objects those threads directly pin. Epoch schemes can make traversal cheaper because a single active interval covers many nodes, but a thread must not silently remain active across unbounded blocking work. Investigate the library’s rules for nested guards, thread deregistration, exceptions, and asynchronous callbacks. Copying a pointer into a callback does not extend a guard’s lifetime unless the API explicitly provides that ownership transfer.

Estimate retention from the workload rather than claiming that reclamation is free. At a steady retirement rate and an approximately fixed delay, rate times delay estimates pending bytes; bursts and stalled participants can exceed that estimate. In the queue lab, interpret arrivals as retirement events and service as reclamation events. For each independent fixed-rate experiment choose Reset, explicitly set both rates, predict, then Play or Step. Compare arrival two with service three against a fresh Reset followed by arrival two and service one. The first drains and the second grows from four initial items. A control edit retains elapsed time and recomputes from that initial backlog, rather than switching reclamation capacity within a retained history. This is only a fluid analogy. It does not implement hazard scans, epoch advancement, pointer reuse, or a proof that a node may safely be freed.