Transcript
Page 1: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 1

Relativistic Red-Black Trees

Philip Howard

10/31/2011

[email protected]

Page 2: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 2

Red-Black Trees

• 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

Page 3: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 3

5

12

15

3 9

7 10

6

4

13 17

14

11

11.5

11.2 11.7

Page 4: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 4

Reasons for RBTrees

• O( log(n) ) performance

• O(1) restructures after insert/delete

• Possibly O( log(n) ) recolors (but recolors are cheap)

Page 5: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 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 external, and depth properties; may violate internal property

Page 6: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 6

5

12

15

3 10

711

6 8

4

13 17

14

9 Insert 9

Page 7: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 7

Delete

• Find node

• If node doesn’t have an external child, swap with next node in in-order traversal order (left most node of the right branch)

• Delete the node from the bottom

Page 8: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 8

5

12

15

3 8

6 10

7

4

13 17

14

11

11.5

11.2 11.7

Swap example: Delete 5

Page 9: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 9

Diag Restructure

A

B

C

1 2

3

4A

B

C

1 2 3 4

Page 10: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 10

Zig Restructure

A

B

C

1

2 3

4 A

B

C

1 2 3 4

Page 11: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 11

Performance

• Find, Insert, Remove

O( log(n) )

• At most 1 restructure on insert

• At most 2 restructures on delete

• Possibly log(n) recolors

Page 12: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 12

Terminology

• synchronize_rcu• rcu_assign_pointer• rcu_dereference• call_rcu• call_rcu(free)

• wait-for-readers• rp-publish• rp-read• defer-for-readers• rp-free

Page 13: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 13

Terminology

Sn the Start of operation n.

Fn the Finish of operation n.

En the Effect of operation n. For example, if operation n is an insert, the effect of that operation is that the tree has a new node.

ab defines a happens-before relation such that a happens before b.

Page 14: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 14

Terminology

if

Sa Sb Fa

or

Sb Sa Fb

then a and b are concurrent and either

Ea Eb or Eb Ea

is possible

Page 15: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 15

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

Page 16: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 16

nodes that “exist in the tree”

i is insert of N

d is delete of N

r is read (lookup or complete traversal)

• If Fi Sr and Fr Sd then N exists in the tree

• If Fr Si or Fd Sr then N does not exist in the tree

Page 17: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 17

nodes that “exist in the tree”i is insert of N

d is delete of N

r is read (lookup or complete traversal)

• If i is concurrent with r then either Ei Er or Er Ei

• If d is concurrent with r then either

Ed Er or Er Ed

Page 18: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 18

nodes that “exist in the tree”

• Any update that strictly precedes a read is observable by that read

• Any update that strictly follows a read is not observable by that read

• Any update that is concurrent with a read may or may not be observable by that read

Page 19: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 19

Relativistic Implementation

Page 20: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 20

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 ADT is a map (not a multimap), then temporarily having a duplicate node in the tree won’t affect lookups

• Mutual exclusion used between writers

Page 21: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 21

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

Page 22: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 22

Diag Restructure

A

B

C

D

F

G

E

H

A

B

C

D

F

GE

H

Page 23: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 23

Diag Restructure

A

B

C

D

F

G

E

H

A

B

C

D

F

G

E

H

A

B

C

D

F

G

E

H

Page 24: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 24

Diag Restructure

A

B

C

D

F

G

E

H

A

B

C

D

F

GE

H

Reader at F looking for D?

Page 25: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 25

Diag Restructure

A

B

C

D

F

G

E

H

A

B

C

D

F

GE

H

F’

A

B

C

D

GE

H

F’

1. init F’2. link F’3. unlink F

Page 26: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 26

RBTree Delete with Swap

D

A

B

E

C

F

null D

A

B

E

C

F

null

C’

A E

D

F

C’

Page 27: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 27

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

Page 28: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 28

Diag Restructure

A

B

C

D

F

G

E

H

A

B

C

D

F

GE

H

Page 29: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 29

RBTree Delete with Swap

D

A

B

E

C

F

null D

A

B

E

C

F

null

C’

A E

D

F

C’

Page 30: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 30

Zig Restructure

A

B

C

1

2 3

4 A

B

C

1 2 3 4

Page 31: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 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

ccavl Concurrent AVL implementation

Page 32: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 32

Read Performance

0

5

10

15

20

25

0 10 20 30 40 50 60 70

Mill

ions

ThreadsOpe

ratio

ns/s

ec

NOLOCK reads

RP reads

ccavl reads

RWL_write reads

RWL_read reads

LOCK reads

Page 33: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 33

Contended Write Performance

0

0.05

0.1

0.15

0.2

0.25

0 10 20 30 40 50 60 70

Mil

lions

Threads

Ope

rati

on/s

ec

NOLOCK writesRP writesccavl writesRWL_write writesRWL_read writes

Page 34: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 34

Linearizability?

Page 35: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 35

Linearizability

• DefinitionEquivalent to a some valid serial execution

• ProofEach operation appears to take effect instantaneously

Page 36: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 36

RP RBTree Properties

• Immutable nodes – key & value don’t change

• Sort – Nodes are always in valid sort order

• Structural Integrity – lookups will always succeed

Page 37: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 37

Lookup

Three options at each node1. correct node was found

2. proceed down left path

3. proceed down right path

Page 38: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 38

LookupLast rp-read is the linearization point

• Immutable nodes means each time we examine a node, we’ll make the same decision

• Sort means we’ll make the right decision at each node

• Structural integrity means concurrent updates won’t break our lookup

Must show that updates maintain these properties

Page 39: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 39

Insert

• rp-publish is the linearization point

• Must show that restructure does not invalidate sort or structural integrity properties

Page 40: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 40

Delete without Swap

• rp-publish is the linearization point (assigning NULL or the single child to the parent of deleted node)

• Must show that restructure does not invalidate sort or structural integrity properties

Page 41: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 41

Swap

D

A

B

E

C

F

null D

A

B

E

C

F

null

C’

A E

D

F

C’

A E

D

F

C’

C

•rp-publish(C’) is linearization point

•Consider linearization point of lookups for B

•Preservation of properties?

Page 42: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 42

Diag Restructure

1

A

2

B

C

4

3

D

1

A

2

B

C

43

D

C’

1

A

2

B

43

D

C’

• Linearization point?• sort?• structural integrity?

Page 43: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 43

Linearizability?

Write 1 Write 2

Reader

Page 44: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 44

5

12

15

3 9

7 10

6

4

13 17

14

11

11.5

11.2 11.7

Traversals

Page 45: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 45

Traversal Options

• Use a stack to represent current location in traversal

• Use parent pointers to track location in traversal

• Other options?

Page 46: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 46

Lookup AssumptionsValid for Traversals?

• 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

Page 47: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 47

Traversal Options

• Reader-Writer lock O(N) traversal – with delayed writes

• Relativistic O( N log(N) ) traversal – with undelayed writes

• Relativistic O(N) traversal – with more complicated writes

Page 48: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 48

Contended Update Performance

0

50000

100000

150000

200000

250000

300000

350000

400000

0 2 4 6 8 10 12 14 16

RP O(N log(N))

RP O(N)

RWL_w rite

Page 49: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 49

Read Performance 64K node tree

0

200

400

600

800

1000

1200

1400

0 2 4 6 8 10 12 14 16

RP O(N log(N) )

RP O(N)

RWL_w rite

Page 50: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 50

Scalability (4 readers)

1

10

100

1000

10000

100000

1000000

10000000

100000000

1 10 100 1000 10000 100000 1000000

rp O(N)

rp O(N log(N))

N

N log(N)

Page 51: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 51

Conclusions

What we gained• Linear scalability for readers• Writer doesn’t interfere with read performance• Read performance approaches that of nolock• Contended write performance exceeds that of

other valid synchronization methods

Page 52: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 52

Conclusions

What we gave up• Uncontended write performance is worse than

with other synchronization methods• Traversal performance

Page 53: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 53

Conclusions

• RP is applicable to complex multi-write update data structures

• wait-for-readers can be used to control the visibility of writes within an update

Page 54: 10/31/20111 Relativistic Red-Black Trees Philip Howard 10/31/2011 phil.w.howard@gmail.com

10/31/2011 54

(an aside)

When is it OK for readers to see updates in different orders?

When updates are independent or commutative

Example: phone bookdeleting a customer and adding a customer are independent UNLESS the new customer gets the old customer’s phone number