33 Concurrency support library [thread]

33.11 Safe reclamation [saferecl]

33.11.3 Hazard pointers [saferecl.hp]

33.11.3.1 General [saferecl.hp.general]

A hazard pointer is a single-writer multi-reader pointer that can be owned by at most one thread at any time.

Only the owner of the hazard pointer can set its value, while any number of threads may read its value.

The owner thread sets the value of a hazard pointer to point to an object in order to indicate to concurrent threads—which may delete such an object—that the object is not yet safe to delete.

A class type T is hazard-protectable if it has exactly one base class of type hazard_pointer_obj_base<T, D> for some D, that base is public and non-virtual, and it has no base classes of type hazard_pointer_obj_base<T2, D2> for any other combination T2, D2.

An object is hazard-protectable if it is of hazard-protectable type.

The time span between creation and destruction of a hazard pointer h is partitioned into a series of protection epochs; in each protection epoch, h either is associated with a hazard-protectable object, or is unassociated.

Upon creation, a hazard pointer is unassociated.

Changing the association (possibly to the same object) initiates a new protection epoch and ends the preceding one.

An object x of hazard-protectable type T is retired with a deleter of type D when the member function hazard_pointer_obj_base<T, D>::retire is invoked on x.

Any given object x shall be retired at most once.

A retired object x is reclaimed by invoking its deleter with a pointer to x; the behavior is undefined if that invocation exits via an exception.

A hazard-protectable object x is possibly-reclaimable with respect to an evaluation A if:

(6.1)
x is not reclaimed; and
(6.2)
x is retired in an evaluation R and A does not happen before R; and
(6.3)
for all hazard pointers h and for every protection epoch E of h during which h is associated with x:
- (6.3.1)
  if the beginning of E happens before R, the end of E strongly happens before A; and
- (6.3.2)
  if E began by an evaluation of try_protect with argument src, label its atomic load operation L.
  If there exists an atomic modification B on src such that L observes a modification that is modification-ordered before B, and B happens before x is retired, the end of E strongly happens before A.
  
  [Note 1:
  In typical use, a store to src sequenced before retiring x will be such an atomic operation B.
  — end note]
[Note 2:
The latter two conditions convey the informal notion that a protection epoch that began before retiring x, as implied either by the happens-before relation or the coherence order of some source, delays the reclamation of x.
— end note]

The number of possibly-reclaimable objects has an unspecified bound.

[Note 3:

The bound can be a function of the number of hazard pointers, the number of threads that retire objects, and the number of threads that use hazard pointers.

— end note]

[Example 1:

The following example shows how hazard pointers allow updates to be carried out in the presence of concurrent readers.

The object of type hazard_pointer in print_name protects the object *ptr from being reclaimed by ptr->retire until the end of the protection epoch.

struct Name : public hazard_pointer_obj_base<Name> { /* details */ }; atomic<Name*> name; // called often and in parallel! void print_name() { hazard_pointer h = make_hazard_pointer(); Name* ptr = h.protect(name); // Protection epoch starts // ... safe to access *ptr } // Protection epoch ends. // called rarely, but possibly concurrently with print_name void update_name(Name* new_name) { Name* ptr = name.exchange(new_name); ptr->retire(); } — end example]