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

Relativistic Red-Black Trees Philip Howard 4/28/2010 pwh@cecs.pdx.edu 4/27/2010 1

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 2

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

Claim • O(1) restructures after insert/delete • Possibly O( log(n) ) recolors • O( log(n) ) performance 4/27/2010 4

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 5

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

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 u u a w v w b c v z c b z 4/27/2010 7

Double Red case 1 • Re-label u,v,z as a,b,c in left to right order (in-order traversal order) • Restructure as: b a u a c w v b z c 4/27/2010 8

Double red (case 2) • Sibling of v is red 10 u w v 3 15 18 z 4/27/2010 9

Double red (case 2) • Re-color u red, w,v black • Recurse up the tree as needed 10 u 10 u w v w 3 15 v 3 15 18 z 18 z 4/27/2010 10

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 11

Swap example: Delete 5 12 11 15 5 11.5 13 17 11.2 11.7 3 8 14 4 6 10 7 4/27/2010 12

Delete (cont) • Remove v with external child w • r is sibling of w • x is parent of v 10 x v 3 15 w 18 r • Remove v and w • Make r a child of x 4/27/2010 13

Delete (cont) • v was red XOR r was red, color r black 10 10 x x v 3 15 3 18 r w 18 r • v was black AND r was black, color r double-black 10 x 10 x r 3 v 3 15 w r 4/27/2010 14

Double Black case 1 • Sibling y of r is black and has a red child z • restructure(z) b x c a c y r b r z a • a and c are black • b is former color of x • r is black 4/27/2010 15

Double Black (case 2) • Sibling y of r is black • Both children of y are black • Recolor x x c c y r y r b b a q a q • color r black • color y red • If x is red, color it black; else color it double black 4/27/2010 16

Double Black (case 3) • Sibling y of r is red x c r y b z 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) 4/27/2010 17

Double Black (case 3) • restructure(z) (note y is always b) • color y black, x red y b x c r z x a c y b r z a 3 1 2 3 • Repeat case 1 or 2 (note that case 2 can’t cascade) 4/27/2010 18

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 19

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 20

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 21

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 22

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 23

Swap example: Delete 5 12 11 15 6’ 5 11.5 13 17 11.2 11.7 3 8 14 4 6 10 7 4/27/2010 24

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 25

Restructure b a u a c w v b z c 4/27/2010 26

Restructure – diag right up a b a’ c 1 2 3 4 4/27/2010 27

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 28

Restructure – zig right up b’ a c 1 b 4 2 3 4/27/2010 29

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 30

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 31

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 32

Read Performance Red/black read tree performance 60 nolock read 64K Millions nolock wread 64K 50 rp read 64K Operations/sec 40 rp wread 64K rwlr read 64K 30 20 10 0 0 10 20 30 40 50 60 70 Threads 4/27/2010 33

Write Performance Red/black write tree performance nolock write 64K rp write 64K 0.9 rwlw write 64K Millions lock write 64K 0.8 rwlr write 64K 0.7 Operations/sec 0.6 0.5 0.4 0.3 0.2 0.1 0 0 10 20 30 40 50 60 70 Threads 4/27/2010 34

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 other valid synchronization methods 4/27/2010 35

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 36

(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 37

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? 4/27/2010 38