{"id":10735,"date":"2025-05-05T11:12:54","date_gmt":"2025-05-05T11:12:54","guid":{"rendered":"https:\/\/www.modernescpp.com\/?p=10735"},"modified":"2025-07-03T14:41:03","modified_gmt":"2025-07-03T14:41:03","slug":"hazard-pointers-in-c26","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/hazard-pointers-in-c26\/","title":{"rendered":"Hazard Pointers in C++26"},"content":{"rendered":"\n

Hazard pointers provide garbage collection in C++ and solve the ABA problem. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

First of all. What is a hazard pointer? Proposal P2530R3 <\/a>gives a nice explanation:<\/p>\n\n\n\n

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. A thread that is about to access dynamic objects acquires ownership of hazard pointer(s) to protect such objects from being reclaimed. The owner thread sets the value of a hazard pointer to point to an object in order to indicate to concurrent threads \u2014 that may remove such object \u2014 that the object is not yet safe to reclaim.
Hazard pointers are owned and written by threads that act as accessors\/protectors (i.e., protect removable objects from unsafe reclamation in order to access such objects) and are read by threads that act as removers\/reclaimers (i.e., may remove and try to reclaim objects). Removers retire removed objects to the hazard pointer library (i.e., pass the responsibility for reclaiming the objects to the library code rather than normally by user code). The set of protector and remover threads may overlap.<\/em><\/p>\n\n\n\n

To make it short, Hazard Pointers guarantee that the referenced objects are deleted if they are no longer needed.<\/strong><\/p>\n\n\n\n

Hazard pointers perform and interact with protection and deferred reclamation.<\/p>\n\n\n\n

Protection <\/h3>\n\n\n\n

They guarantee that objects are only destroyed if they are no longer needed.<\/p>\n\n\n\n

Deferred Reclamation<\/h3>\n\n\n\n

Collect the retired objects and extract their values into a set. Read the values of all hazard pointers and compare them with the addresses of the extracted values in the set. If a value from the set is not found in all values of the hazard pointers, it can be destroyed. If found, it will go back in the set of retired objects. <\/p>\n\n\n\n

So, what are the advantages of hazard pointers? My answer consists of two points: correctness and performance.<\/p>\n\n\n\n

Advantage<\/h2>\n\n\n\n

I would like to start with correctness.<\/p>\n\n\n\n

Correctness<\/h3>\n\n\n\n

The advantage of hazard pointers can be illustrated with a simple example.<\/p>\n\n\n\n

Node*<\/span> currentNode =<\/span> this<\/span>-><\/span>head;\nNode*<\/span> nextNode =<\/span> currentNode-><\/span>next;\n<\/pre><\/div>\n\n\n\n
The critical question regarding this small code snippet is: how can we guarantee that currentNode <\/code>is still valid? While one thread is executing this code, another thread may already be executing currentNode<\/code>.

Atomic compare-and-swap <\/a>(CAS) operations exacerbate this problem. In C++, the compare_exchange_strong<\/code> operation is typically used for this purpose. However, CAS operations suffer from the ABA problem. I discuss the ABA problem in more detail in my article Deferred Reclamation in C++26: Read-Copy Update and Hazard Pointers<\/a>. The solution to the problem is relatively obvious: automatic garbage collection. This is exactly what hazard pointers offer.<\/p>\n\n\n\n
Performance<\/h3>\n\n\n\n

With C++14, reader-writer locks were introduced. With these special locks, reading threads are treated differently than writing threads. This means that any number of reading threads can be executed simultaneously, but only one writing thread. As a result, reader-writer locks promise a performance improvement over exclusive locks. More details on reader-writer locks can be found in my earlier article Reader-Writer Locks<\/a>.<\/p>\n\n\n\n

Proposal P2530R3<\/a> provides a nice example of a data structure that is predominantly read. A classic reader-writer lock and hazard pointer are used.

<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n


Typical latency of hazard_pointer construction\/destruction in the Folly implementation on contemporary commodity server is approximately 4 ns. Using a pre-constructed hazard_pointer typically takes under one nanosecond to stop for protection.<\/em><\/p>\n\n\n\n
Facebook’s open library Folly<\/a> provides the reference implementation of hazard pointers.<\/p>\n\n\n\n
Interface<\/h2>\n\n\n\n


Hazard Pointers consisting of the two classes hazard_pointer_obj_base<\/code> and hazard_pointer <\/code>and the two functions make_hazard_pointer<\/code> and swap<\/code>.<\/p>\n\n\n\n
    \n
  • hazard_pointer_obj_base<\/code> is the base class of the protected class, and provides the function retire<\/code>.<\/li>\n\n\n\n
  • hazard_pointer<\/code> provides the functions empty, protect, try_protect, reset_protection,<\/code>and swap.<\/code><\/li>\n\n\n\n
  • make_hazard_pointer<\/code> creates a hazard pointer.<\/li>\n<\/ul>\n\n\n\n
    What’s next?<\/h2>\n\n\n\n
    RCU stands for Read Copy Update, a synchronization technique for almost read-only data structures created by Paul McKenney and used in the Linux kernel since 2002. RCU is currently mentioned in connection with hazard pointers.<\/p>\n\n\n\n






    <\/p>\n","protected":false},"excerpt":{"rendered":"
    Hazard pointers provide garbage collection in C++ and solve the ABA problem. First of all. What is a hazard pointer? Proposal P2530R3 gives a nice explanation: 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 […]<\/p>\n","protected":false},"author":21,"featured_media":10449,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[559],"tags":[563],"class_list":["post-10735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c26-blog","tag-hazard-pointers"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/10735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=10735"}],"version-history":[{"count":7,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/10735\/revisions"}],"predecessor-version":[{"id":10747,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/10735\/revisions\/10747"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/10449"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=10735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=10735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=10735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}