Relativistic Red-Black Trees Philip Howard 4/28/2010 - - PowerPoint PPT Presentation

4/27/2010 1

Relativistic Red-Black Trees

Philip Howard 4/28/2010 pwh@cecs.pdx.edu

4/27/2010 2

Red-Black Trees

• Root Property: The root is black
• External Property: Every external node is

black

• Internal Property: The children of red

nodes are black

• Depth Property: All external nodes have

the same black depth

4/27/2010 3

5 12 15 3 9 7 10 6 4 13 17 14 11 11.5 11.2 11.7

4/27/2010 4

Claim

• O(1) restructures after insert/delete
• Possibly O( log(n) ) recolors
• O( log(n) ) performance

4/27/2010 5

Insertion

• Search until we get to external node
• Insert at this location adding two empty,

black, external nodes underneath

• If root, color black, else color red
• Preserves root, external, and depth

properties, may violate internal property

4/27/2010 6

5 12 15 3 10 7 11 6 8 4 13 17 14 9 Insert 9

4/27/2010 7

Double Red case 1

• z is the new node
• v,u are parent and grandparent of new

node

• Sibling w of v is black

a b c z v u w a b c w u v z

4/27/2010 8

Double Red case 1

• Re-label u,v,z as a,b,c in left to right order

(in-order traversal order)

• Restructure as:

c a b a b c z v u w

4/27/2010 9

Double red (case 2)

• Sibling of v is red

10 15 18 z v u w 3

4/27/2010 10

Double red (case 2)

10 15 18 z v u w 3

• Re-color u red, w,v black
• Recurse up the tree as needed

10 15 18 z v u w 3

4/27/2010 11

Delete

• Find node
• If node doesn’t have an external child,

swap with next internal node in in-order traversal order (left most node of the right branch)

• Delete the node from the bottom

4/27/2010 12

5 12 15 3 8 6 10 7 4 13 17 14 11 11.5 11.2 11.7

Swap example: Delete 5

4/27/2010 13

Delete (cont)

• Remove v with external child w
• r is sibling of w
• x is parent of v

10 15 18 r v x w 3

• Remove v and w
• Make r a child of x

4/27/2010 14

Delete (cont)

10 15 18 r v x w 3

• v was red XOR r was red, color r black

10 18 r x 3

• v was black AND r was black, color r double-black

10 15 r v x w 3 10 r x 3

4/27/2010 15

Double Black case 1

• Sibling y of r is black and has a red child z
• restructure(z)

c r x b y a z c r b a

• a and c are black
• b is former color of x
• r is black

4/27/2010 16

Double Black (case 2)

• Sibling y of r is black
• Both children of y are black
• Recolor

c r x b y a q

• color r black
• color y red
• If x is red, color it black; else color it double black

c r x b y a q

4/27/2010 17

Double Black (case 3)

• Sibling y of r is red

c r x b y a q

• if y is right child of x, z is right child of y
• if y is left child of x, z is left child of y
• restructure(z) (note y is always b)

z

4/27/2010 18

Double Black (case 3)

c r x b y a 2

• restructure(z) (note y is always b)
• color y black, x red

z c r x b y a 3 z 1 3

• Repeat case 1 or 2 (note that case 2 can’t

cascade)

4/27/2010 19

Performance

• Find, Insert, Remove

O( log(n) )

• At most 1 restructure on insert
• At most 2 restructures on delete
• Possibly log(n) recolors

4/27/2010 20

Relativistic Requirements

• Readers don’t block, and are not inhibited

by writers

• Lookups always find a node that exists in

the tree

• Traversals always return nodes in the

correct order without skipping any nodes that exist in the tree

4/27/2010 21

nodes that “exist in the tree”

• Every node that was in the tree at the

beginning of a read and was not deleted during the read

• Some nodes that were deleted during a

read

• Some nodes that were inserted during a

read

4/27/2010 22

Assumptions

• Readers ignore the color of nodes
• Readers don’t need to access the parent

pointers (note: some traversal algorithms require access to parent pointers)

• If keys are unique, temporarily having a

duplicate node in the tree won’t affect reads

• Mutual exclusion used between writers

4/27/2010 23

Operations

Insertion No nodes are moved or freed so this operation is safe. Recolor Recoloring does not affect the read consistency of the tree. Delete Need to defer reclamation of memory until no thread has a reference to the deleted node. Swap Need to guarantee that the node which moves up isn’t missed by readers between the new and old position. Restructures Requires moving nodes. Need to ensure that no readers get lost in the transition.

4/27/2010 24

5 12 15 3 8 6 10 7 4 13 17 14 11 11.5 11.2 11.7

Swap example: Delete 5

6’

4/27/2010 25

Swap algorithm

find node to delete find swap candidate create swap-prime link swap-prime into tree wait a grace period remove swap from tree

4/27/2010 26

Restructure

c a b a b c z v u w

4/27/2010 27

Restructure – diag right

a b c 1 2 3 4 a’ up

4/27/2010 28

Diag algorithm

Create copy of A. Label copy A’. A’ children are child of a and child of B link A’ into tree as child of B link around A: B becomes child of up

4/27/2010 29

Restructure – zig right

a c b 1 2 3 4 up b’

4/27/2010 30

zig algorithm

Create copy of B. Label copy B’ B’ children are A and C B’ becomes child of UP Wait a grace period Children of B become children of A and C

4/27/2010 31

Traversals

• O(n): requires structure of tree to be

maintained (no updates allowed)

– Use parent pointers to find next()

• O(n log(n)): allows concurrent updates

– Start search for next() at root of tree

4/27/2010 32

Performance

nolock No synchronization – NOT A VALID IMPLEMENTATION lock pthread mutex lock rwlr Reader-Writer lock that favors readers rwlw Reader-Writer lock that favors writers rp Relativistic Programming implentation

4/27/2010 33

Read Performance

Red/black read tree performance

10 20 30 40 50 60 10 20 30 40 50 60 70 Millions Threads Operations/sec nolock read 64K nolock wread 64K rp read 64K rp wread 64K rwlr read 64K

4/27/2010 34

Write Performance

Red/black write tree performance

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10 20 30 40 50 60 70 Millions Threads Operations/sec nolock write 64K rp write 64K rwlw write 64K lock write 64K rwlr write 64K

4/27/2010 35

Conclusions

What we gained

• Linear scalability for readers
• Writer doesn’t interfere with read performance
• Read performance approachs that of nolock
• Contended write performance exceeds that of
• ther valid synchronization methods

4/27/2010 36

Conclusions

What we gave up

• Uncontended write performance is worse than

with other synchronization methods

• Readers may see updates in different orders

4/27/2010 37

(an aside)

When is it OK for readers to see updates in different orders? When updates are independent or commutative Example: phone book

deleting a customer and adding a customer are independent UNLESS the new customer gets the old customer’s phone number

4/27/2010 38

On going work

• Benchmark against a TM-ish, NBS-ish

concurrent algorithm

• Remove the grace period from

restructures

• Remove the grace period from swap
• Allow multiple concurrent updates
• O(n) traversal with concurrent updates
• Answer the general question: What makes

an algorithm/data structure RP friendly?