{"id":10563,"date":"2025-01-27T12:23:43","date_gmt":"2025-01-27T12:23:43","guid":{"rendered":"https:\/\/www.modernescpp.com\/?p=10563"},"modified":"2025-07-03T14:30:34","modified_gmt":"2025-07-03T14:30:34","slug":"deferred-reclamation-in-c26-read-copy-update-and-hazard-pointers","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/deferred-reclamation-in-c26-read-copy-update-and-hazard-pointers\/","title":{"rendered":"Deferred Reclamation in C++26: Read-Copy Update and Hazard Pointers"},"content":{"rendered":"\n

Before I dive into lock-free programming, there’s a little bit of theory necessary.<\/p>\n\n\n\n

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

A common problem in concurrency is the so-called ABA problem. That means you read a variable twice, which returns the same value each time, A. Therefore, you conclude that nothing changed in between. But you forgot the B.<\/p>\n\n\n\n

Let me first use a simple scenario to introduce the problem.<\/p>\n\n\n\n

<\/span>An Analogy<\/span><\/h2>\n\n\n\n

The scenario involves you sitting in a car and waiting for the traffic light to turn green. In our case, green stands for B, and red for A. What\u2019s happening?<\/p>\n\n\n\n

    \n
  1. You look at the traffic light, and it is red (A).<\/li>\n\n\n\n
  2. Because you are bored, you begin to check the news on your smartphone and forget the time.<\/li>\n\n\n\n
  3. You look once more at the traffic light. Damn, is still red (A).<\/li>\n<\/ol>\n\n\n\n

    Of course, the traffic light became green (B) between your two checks. Therefore, what seems to be one red phase was two.<\/p>\n\n\n\n

    What does this mean for threads (processes)? Now, once more formal.<\/p>\n\n\n\n

      \n
    1. Thread 1 reads a variable var with value A.<\/li>\n\n\n\n
    2. Thread 1 is preempted, and thread 2 runs.<\/li>\n\n\n\n
    3. Thread 2 changes the variable var from A to B to A.<\/li>\n\n\n\n
    4. Thread 1 starts to execute and checks the value of variable var; because the value of variable var is the same, thread 1 continues with its work,<\/li>\n<\/ol>\n\n\n\n

      Often, that is a no-brainer. You can ignore it.<\/p>\n\n\n\n

      <\/span>Atomic Multiplication<\/span><\/h2>\n\n\n\n

      Have a look at it here. The function fetch_mult <\/code>(1) multiplies a std::atomic<T>&<\/code> shared by mult<\/code>. <\/p>\n\n\n\n

      \/\/ fetch_mult.cpp<\/span>\n\n#include <atomic><\/span>\n#include <iostream><\/span>\n\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nT fetch_mult(std::<\/span>atomic<<\/span>T>&<\/span> shared, T mult){                          \/\/ 1<\/span>\n  T oldValue =<\/span> shared.load();                                          \/\/ 2<\/span>\n  while<\/span> (!<\/span>shared.compare_exchange_strong(oldValue, oldValue *<\/span> mult));  \/\/ 3<\/span>\n  return<\/span> oldValue;\n}\n\nint<\/span> main(){\n  std::<\/span>atomic<<\/span>int<\/span>><\/span> myInt{5<\/span>};\n  std::<\/span>cout <<<\/span> myInt <<<\/span> '\\n'<\/span>;          \n  fetch_mult(myInt,5<\/span>);\n  std::<\/span>cout <<<\/span> myInt <<<\/span> '\\n'<\/span>;         \n}\n<\/pre><\/div>\n\n\n\n
      <\/p>\n\n\n\n
      shared.compare_exchange_strong(expected, desired)<\/code>(3) has the following behavior:<\/p>\n\n\n\n