Maged M. Michael, “Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects”

1. Maged M. Michael, “Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects” Presentation Robert T. Bauer

2. The Problem • Lock-free approaches scale (with the number of processors) and avoid deadlock issues. • Lock-free means concurrent access which is problematic for storage reclamation • Previous papers described lock-free techniques that updated in place or assumed dedicated constant width data; i.e., storage was not collected and reused.

3. The Constraints • Detection Property: • Distinguish live objects from garbage • Reclamation Property: • Reclaim garbage objects’ storage • Safety Properties: • Cannot reclaim “live” objects • Cannot access reclaimed objects • Liveness Property: • “Garbage” objects eventually reclaimed Note: These are more than those identified in the paper

4. The Lock-Free Idea • Do all the “work” on the side, but accessible from a pointer • Use CAS to update, in place, the pointer • Do this in a loop *p_new = new data do { p_old = p … … } while (!cas(&p, p_old, p_new)) When can this be collected (reclaimed)?

5. push(node): do { t = TOP nodenext = TOP } until CAS(&TOP,t,node) node pop: do { t = TOP if t == NULL return NULL next = tnext } until CAS(&TOP,t,next) return t Example: Lock-Free Stack

6. ABA Problem • Suppose a list has A  B  C • Thread X: t = TOP; …; next = tnext • Thread Y: N = POP: t = TOP; …; next = tnext; CAS(&TOP, t, next) POP: t = TOP; …; next = tnext; CAS(&TOP, t, next) List is now just “C”, since A and B have been popped PUSH(N): t = TOP; Anext = TOP; CAS (&TOP, t, A) List is now “AC”, since we pushed A • Thread X continues: cas(&TOP,t,next) List is now “BC” • Issue: What if Thread “Y” had reclaimed “B” because it “knew” that it would never use it?

7. POP With Tags node pop: do { <t, tag> = TOP if t == null return null next = tnext } until CAS(&TOP, <t,tag>, <next,tag+1>) return t Since tag is monotonic with respect to calls to pop, the A—B—A problem is eliminated as long the number of calls to pop is limited.

8. Hazard Pointer Thread 0 1 2 … n Hazard Pointers Hazard Pointers identify the objects that the thread will access. Objects

9. “Releasing” an Object to be released Thread n When the “object” is released by thread n, the pointer on the hazard list is removed. We add the pointer to the object to the “to be released” list. After the object reference is added to the List we check the length of the list and if it is greater than “R”, we “scan” to see what can be reclaimed.

10. Reclaiming Storage hp_1 hp_2 hp_n Thread n, scans the hp_i lists for each thread, if ptr_k not any hp list, then it can be reclaimed. ptr_k

11. Problem 1 of 2 • Problem 1: • Thread X removes node N ptr (count < R) • Thread Y removes node N ptr (count >= R) • Scan and reclaim N • Thread X removes node M ptr (count >= R) • Scan and reclaim N

12. Problem 2 of 2 Thread X scans list for “u”. At this “point”, thread Y runs and adds “u”. Thread Y HP list free Thread Y HP list u Since Thread X did not see “M” it will reclaim the storage. But, Y has “M” on its hazard list.

13. Transforming a FIFO Queue: Identifying the hazards Access hazard because *t may have been removed and reclaimed ABA hazards Access and ABA hazard ABA hazard Note: Only one hazard pointer is needed, since “t” is the only hazard reference.

14. Transforming a FIFO Queue: Adding hazard pointers Protect *t data This is supposed to make sure that t is “safe” – that the “t” protected by hp0 is The same as Tail So, hp0 “protects” t only during the time this routine is active; but, it might protect it much longer!

15. Transforming a FIFO Queue: Dequeue Don’t’ want head to be reclaimed. We will use it later! h (head) will end up on the “to be released” list. Note that “next” is still on the hp list – so I am not sure how another processor can retire it?

16. Double Linked List: Something Curious What’s this about?

17. Performance Performance of FIFO queue

18. Performance Hash Table: Load Factor = 5

19. Author Notes • Superior Performance of hazard pointers • operate directly on shared objects without need for managing locks • read-only operations do not result in writes other than private hazard pointers • no spinning • progress guaranteed under preemption

20. Conclusion (mine) • Paper’s attempt at formalism was not useful • Idea of hazard pointers is simple, but implementations are broken in one way or another • Author seems confused about ABA problem and garbage collection