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

Presentation

Robert T. Bauer

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.

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

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 datado {

p_old = p……

} while (!cas(&p, p_old, p_new))

When can this be collected (reclaimed)?

Example: Lock-Free Stack

push(node):do {

t = TOPnodenext =

TOP} until

CAS(&TOP,t,node)

node pop:do {

t = TOPif t == NULL

return NULLnext = tnext

} untilCAS(&TOP,t,next)

return t

ABA Problem• Suppose a list has A B C• Thread X:

t = TOP; …; next = tnext

• Thread Y:N = POP: t = TOP; …; next = tnext; CAS(&TOP, t, next)POP: t = TOP; …; next = tnext; CAS(&TOP, t, next)

List is now just “C”, since A and B have been poppedPUSH(N): t = TOP; Anext = TOP; CAS (&TOP, t, A)

List is now “AC”, since we pushed A

• Thread X continues:cas(&TOP,t,next)

List is now “BC”

• Issue: What if Thread “Y” had reclaimed “B” because it “knew” that it would never use it?

POP With Tags

node pop:do {

<t, tag> = TOPif t == null

return nullnext = tnext

} 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.

Hazard PointerThread 0 1 2 … n Hazard Pointers

Objects

Hazard Pointers identify theobjects that the thread willaccess.

“Releasing” an ObjectThread 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 theList we check the length of the list andif it is greater than “R”, we “scan” to see what can be reclaimed.

to be released

Reclaiming Storagehp_1 hp_2 hp_n

Thread n, scansthe hp_i lists foreach thread, if ptr_knot any hp list, thenit can be reclaimed.

ptr_k

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

Problem 2 of 2

free

Thread X scans list for “u”.At this “point”, thread Y runsand adds “u”.

Thread Y HP list

Thread Y HP list

u

Since Thread X did not see “M” it will reclaimthe storage. But, Y has “M” on its hazardlist.

Transforming a FIFO Queue: Identifying the hazards

Access hazard because*t may have been removedand reclaimed

ABA hazards

Access and ABA hazard

ABA hazard

Note: Only one hazard pointer is needed, since “t” is the only hazardreference.

Transforming a FIFO Queue: Adding hazard pointers

Protect *t data

This is supposed to makesure that t is “safe” – thatthe “t” protected by hp0 isThe same as Tail

So, hp0 “protects” t onlyduring the time this routineis active; but, it mightprotect it much longer!

Transforming a FIFO Queue: Dequeue

Don’t’ want head to bereclaimed. We willuse it later!

h (head) will end up on the“to be released” list. Notethat “next” is still on thehp list – so I am not surehow another processorcan retire it?

Double Linked List: Something Curious

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.What’s this about?

Performance

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Performance of FIFO queue

Performance

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Hash Table: Load Factor = 5

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

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