Hazard pointers

Posted Oct 3, 2024 12:01 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624)
In reply to: Hazard pointers by jseigh
Parent article: The RCU API, 2024 edition

The C++ Hazard Pointers API was informed by some years of production experience with the implementation in the Folly library. As you might guess, Maged Michael was the force behind this implementation, the experience with it, and of course with the adjustments undertaken in response to that experience. On the other hand, and to your point, it is not unusual for such experience to result in increased complexity. Linux-kernel RCU is most certainly another example of this tendency, after all. ;-)

That said, I completely agree that if you can achieve your goals simply, then embrace simplicity. In particular, if a simple lock-free queue does the job for you, then by all means use that queue!

At one point, I had hoped that the various hardware transactional memory mechanisms would be useful for many things, including vCPU preemption. And perhaps someday they will. But at present, they seem to have fallen victim to the same "complexity surprise" called out above.

Hazard pointers

Posted Oct 17, 2024 12:32 UTC (Thu) by jseigh (guest, #173778) [Link]

I gave up on the idea of a hazard pointer implementation as soon as I realized it would involve writing a tracing garbage collector of sorts as part of that.

I did remove the hazard pointer logic from smrproxy. Absent the load of the address of the reader lock object, a lock action is 2 machine instructions, a load register followed by a store register. No loop so it is formally wait-free. Unlock is same as before, a store of 0 to memory. I'm starting on porting it to c++ which also involves figuring out what a c++ deferred reclamation API looks like.