Linearizability & CAP Announcements No hours this week. - - PowerPoint PPT Presentation

▶
linearizability cap announcements
SMART_READER_LITE
LIVE PREVIEW

Linearizability & CAP Announcements No hours this week. - - PowerPoint PPT Presentation

Nov 18, 2023 317 likes •2.18k views

Linearizability & CAP Announcements No hours this week. Announcements No hours this week. Sorry am traveling starting tomorrow. Announcements No hours this week. Sorry am traveling starting tomorrow. Lab 1 goes out

slide-1
SLIDE 1

Linearizability & CAP

slide-2
SLIDE 2

Announcements

  • No hours this week.
slide-3
SLIDE 3

Announcements

  • No hours this week.
  • Sorry am traveling starting tomorrow.
slide-4
SLIDE 4

Announcements

  • No hours this week.
  • Sorry am traveling starting tomorrow.
  • Lab 1 goes out next week.
slide-5
SLIDE 5

Announcements

  • No hours this week.
  • Sorry am traveling starting tomorrow.
  • Lab 1 goes out next week.
  • On requiring summaries vs adding labs.
slide-6
SLIDE 6

Linearizability

slide-7
SLIDE 7

Concurrency not Distributed Systems?

  • Linearizability isn't necessarily about being in a distributed setting.
slide-8
SLIDE 8

Concurrency not Distributed Systems?

  • Linearizability isn't necessarily about being in a distributed setting.
  • Need to worry about operation order even within a single machine.
slide-9
SLIDE 9

Concurrency not Distributed Systems?

  • Linearizability isn't necessarily about being in a distributed setting.
  • Need to worry about operation order even within a single machine.
  • Consider multicore, multiple processes, and other sources of concurrency.
slide-10
SLIDE 10

Concurrency not Distributed Systems?

  • Linearizability isn't necessarily about being in a distributed setting.
  • Need to worry about operation order even within a single machine.
  • Consider multicore, multiple processes, and other sources of concurrency.
  • A property where we are not considering anything about failures.
slide-11
SLIDE 11

Concurrency not Distributed Systems?

  • Linearizability isn't necessarily about being in a distributed setting.
  • Need to worry about operation order even within a single machine.
  • Consider multicore, multiple processes, and other sources of concurrency.
  • A property where we are not considering anything about failures.
  • That comes with the CAP bit later.
slide-12
SLIDE 12

Two Core Ideas

  • Reasoning about concurrent operations.
  • Building concurrent data structures from others.
slide-13
SLIDE 13

Reasoning about Concurrent Operations

  • What is the problem?
slide-14
SLIDE 14

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior
slide-15
SLIDE 15

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

X enqueue(X)

slide-16
SLIDE 16

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

X Y enqueue(X) enqueue(Y)

slide-17
SLIDE 17

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

Y enqueue(X) enqueue(Y) dequeue()

slide-18
SLIDE 18

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

Y Z enqueue(X) enqueue(Y) enqueue(Z) dequeue()

slide-19
SLIDE 19

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

Z enqueue(X) enqueue(Y) enqueue(Z) dequeue() dequeue()

slide-20
SLIDE 20

Reasoning about Concurrent Operations

  • What is the problem?
  • Tend to specify correctness in terms of sequential behavior

enqueue(X) enqueue(Y) enqueue(Z) dequeue() dequeue() dequeue()

slide-21
SLIDE 21

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) enqueue(Z) dequeue() dequeue() dequeue() Process 1 Process 2

slide-22
SLIDE 22

Reasoning about Concurrent Operations

$0

slide-23
SLIDE 23

Reasoning about Concurrent Operations

NYU: Deposit $100 $100

slide-24
SLIDE 24

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 $70

slide-25
SLIDE 25

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 $10

slide-26
SLIDE 26

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 $70

slide-27
SLIDE 27

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60

slide-28
SLIDE 28

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 $0

slide-29
SLIDE 29

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 Amazon: Withdraw $30 $30

slide-30
SLIDE 30

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 Amazon: Withdraw $30 Amtrack: Withdraw $80 $110

slide-31
SLIDE 31

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 Amazon: Withdraw $30 Amtrack: Withdraw $80 Xi'an: Withdraw $10 $120

slide-32
SLIDE 32

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $40

slide-33
SLIDE 33

Reasoning about Concurrent Operations

NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60 NYU: Deposit $100 Amazon: Withdraw $30 Amtrack: Withdraw $80 Amtrack: Refund $80 Xi'an: Withdraw $10 $60

slide-34
SLIDE 34

Reasoning about Concurrent Operations

Process 1 Process 2

slide-35
SLIDE 35

Reasoning about Concurrent Operations

Process 1 Process 2

slide-36
SLIDE 36

Reasoning about Concurrent Operations

enqueue(X) Process 1 Process 2 X

slide-37
SLIDE 37

Reasoning about Concurrent Operations

enqueue(X) Process 1 Process 2 X

slide-38
SLIDE 38

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) Process 1 Process 2 X Y

slide-39
SLIDE 39

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) dequeue() Process 1 Process 2 Y

slide-40
SLIDE 40

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) dequeue() Process 1 Process 2 Y

slide-41
SLIDE 41

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) dequeue() dequeue() Process 1 Process 2

slide-42
SLIDE 42

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) enqueue(Z) dequeue() dequeue() Process 1 Process 2 Z

slide-43
SLIDE 43

Reasoning about Concurrent Operations

enqueue(X) enqueue(Y) enqueue(Z) dequeue() dequeue() dequeue() Process 1 Process 2

slide-44
SLIDE 44

Reasoning about Concurrent Operations

Process 1 Process 2

Correct?

slide-45
SLIDE 45

Reasoning about Concurrent Operations

Process 1 Process 2

Any concerns with always using locks? Correct?

slide-46
SLIDE 46

Reasoning about Concurrent Operations

  • Would like to reason about operations without requiring a lock.
slide-47
SLIDE 47

Reasoning about Concurrent Operations

  • Would like to reason about operations without requiring a lock.
  • Locks require all other threads of execution to block, wait their turn.
slide-48
SLIDE 48

Reasoning about Concurrent Operations

  • Would like to reason about operations without requiring a lock.
  • Locks require all other threads of execution to block, wait their turn.
  • Limited benefit for performance.
slide-49
SLIDE 49

Reasoning about Concurrent Operations

  • Would like to reason about operations without requiring a lock.
  • Locks require all other threads of execution to block, wait their turn.
  • Limited benefit for performance.
  • Also brings on questions about granularity of locks.
slide-50
SLIDE 50

Concurrency Model

  • What sets of ordering are valid?
slide-51
SLIDE 51

Concurrency Model

  • What sets of ordering are valid?
  • Possible concerns:
slide-52
SLIDE 52

Concurrency Model

  • What sets of ordering are valid?
  • Possible concerns:
  • Does the ordering need to match wall clock time?
slide-53
SLIDE 53

Concurrency Model

  • What sets of ordering are valid?
  • Possible concerns:
  • Does the ordering need to match wall clock time?
  • Do we need to preserve ordering for operations in a process?
slide-54
SLIDE 54

Concurrency Model

  • What sets of ordering are valid?
  • Possible concerns:
  • Does the ordering need to match wall clock time?
  • Do we need to preserve ordering for operations in a process?
  • Do we need to preserve ordering for operations across objects?
slide-55
SLIDE 55

Concurrency Model

  • What sets of ordering are valid?
  • Possible concerns:
  • Does the ordering need to match wall clock time?
  • Do we need to preserve ordering for operations in a process?
  • Do we need to preserve ordering for operations across objects?
  • ...
slide-56
SLIDE 56

Linearizability

  • Real Time: An operation takes effect between invocation and return.
  • Changes must be visible after return.
  • Local: If history for each object is sequential then entire history is sequential.
slide-57
SLIDE 57

When are histories linearizable?

slide-58
SLIDE 58

Is Linearizable?

A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() B: q.deq() B: q.OK(y) A: q.OK(z) A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(y) A: q.OK() A: q.deq() B: q.deq() B: q.OK(x) A: q.OK(z)

slide-59
SLIDE 59

Is Linearizable?

A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() B: q.deq() B: q.OK(y) A: q.OK(z) A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(y) A: q.OK() A: q.deq() B: q.deq() B: q.OK(x) A: q.OK(z) Yes

slide-60
SLIDE 60

Is Linearizable?

A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() B: q.deq() B: q.OK(y) A: q.OK(z) A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(y) A: q.OK() A: q.deq() B: q.deq() B: q.OK(x) A: q.OK(z) Yes No

slide-61
SLIDE 61

Is Linearizable?

A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() B: q.deq() B: q.OK(y) A: q.OK(z) A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(y) A: q.OK() A: q.deq() B: q.deq() B: q.OK(x) A: q.OK(z) Yes No A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq()

slide-62
SLIDE 62

Is Linearizable?

A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() B: q.deq() B: q.OK(y) A: q.OK(z) A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(y) A: q.OK() A: q.deq() B: q.deq() B: q.OK(x) A: q.OK(z) Yes No A: q.enq(x) A: q.OK() B: q.enq(y) B: q.OK() A: q.enq(z) B: q.deq() B: q.OK(x) A: q.OK() A: q.deq() Yes

slide-63
SLIDE 63

Sequential Consistency

  • Operations in a single process happen in the same order.
  • Globally operations happen in some sequential order across processes.

Process 1 Process 2 inv(op1) inv(op3) res(op1) inv(op2) res(op2) res(op3) inv(op4) res(op4)

slide-64
SLIDE 64

Sequential Consistency

Process 1 Process 2 inv(op1) inv(op3) res(op1) inv(op2) res(op2) res(op3) inv(op4) res(op4)

slide-65
SLIDE 65

Sequential Consistency

Process 1 Process 2 inv(op1) inv(op3) res(op1) inv(op2) res(op2) res(op3) inv(op4) res(op4)

inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4)

slide-66
SLIDE 66

Sequential Consistency

Process 1 Process 2 inv(op1) inv(op3) res(op1) inv(op2) res(op2) res(op3) inv(op4) res(op4)

inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4) inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4)

slide-67
SLIDE 67

Sequential Consistency

Process 1 Process 2 inv(op1) inv(op3) res(op1) inv(op2) res(op2) res(op3) inv(op4) res(op4)

inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4) inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4) inv(op1) res(op1) inv(op3) res(op3) inv(op2) res(op2) inv(op4) res(op4)

slide-68
SLIDE 68

Sequential Consistency

slide-69
SLIDE 69

Sequential Consistency

  • Not real time. Why?
  • Not local. Why?
slide-70
SLIDE 70

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.ok(Y) q.deq() q.ok(X) p q

slide-71
SLIDE 71

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.ok(Y) q.deq() q.ok(X) p q

slide-72
SLIDE 72

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.ok(Y) q.deq() q.ok(X) p q X

slide-73
SLIDE 73

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.ok(Y) q.deq() q.ok(X) p q X

slide-74
SLIDE 74

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.ok(Y) q.enq(Y) q.deq() q.ok(X) p q X

slide-75
SLIDE 75

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.ok(Y) q.enq(Y) q.deq() q.ok(X) p q X Y

slide-76
SLIDE 76

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.ok(Y) q.enq(Y) q.OK( ) q.deq() q.ok(X) p q X Y

slide-77
SLIDE 77

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) p.ok(Y) q.enq(Y) q.OK( ) q.deq() q.ok(X) p q X Y

slide-78
SLIDE 78

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) p.ok(Y) q.enq(Y) q.OK( ) q.deq() q.ok(X) p q X Y X

slide-79
SLIDE 79

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.ok(Y) q.enq(Y) q.OK( ) q.deq() q.ok(X) p q X Y X

slide-80
SLIDE 80

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) q.deq() q.ok(X) p q X Y X

slide-81
SLIDE 81

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) q.deq() q.ok(X) p q X Y X Y

slide-82
SLIDE 82

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() q.ok(X) p q X Y X Y

slide-83
SLIDE 83

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() q.ok(X) p q X Y X Y

slide-84
SLIDE 84

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(X) q.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() q.ok(X) p q X Y X Y

slide-85
SLIDE 85

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p q

slide-86
SLIDE 86

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) p q

slide-87
SLIDE 87

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) p q Y

slide-88
SLIDE 88

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) q.OK( ) p q Y

slide-89
SLIDE 89

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) q.OK( ) p.enq(Y) p q Y

slide-90
SLIDE 90

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) q.OK( ) p.enq(Y) p q Y Y

slide-91
SLIDE 91

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) p q Y Y

slide-92
SLIDE 92

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) p q Y Y

slide-93
SLIDE 93

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) p q X Y Y

slide-94
SLIDE 94

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) p q X Y Y

slide-95
SLIDE 95

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) p q X Y q.enq(X) q.OK( ) X

slide-96
SLIDE 96

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() p q X Y q.enq(X) q.OK( ) X

slide-97
SLIDE 97

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() q.ok(X) p q X Y q.enq(X) q.OK( ) X

slide-98
SLIDE 98

Sequential Consistency

A: p.enq(x) A: p.OK() B: q.enq(y) B: q.OK() A: q.enq(x) A: q.OK() B: p.enq(y) B: p.OK() A: p.deq() A: p.OK(y) B: q.deq() B: q.OK(x) Process A Process B p.enq(x) p.OK( ) p.deq() p.ok(Y) q.enq(Y) q.OK( ) p.enq(Y) p.OK( ) q.deq() q.ok(X) p q X Y q.enq(X) q.OK( ) X

slide-99
SLIDE 99

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
slide-100
SLIDE 100

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
  • Basic extension: consider multiple operations at a time rather than one operation.
slide-101
SLIDE 101

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
  • Basic extension: consider multiple operations at a time rather than one operation.
  • Serializability: Multiple operations occur in some order.
slide-102
SLIDE 102

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
  • Basic extension: consider multiple operations at a time rather than one operation.
  • Serializability: Multiple operations occur in some order.
  • Make it appear like a group of operations committed at the same time.
slide-103
SLIDE 103

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
  • Basic extension: consider multiple operations at a time rather than one operation.
  • Serializability: Multiple operations occur in some order.
  • Make it appear like a group of operations committed at the same time.
  • Strict Serializability: Serializability + require everything is real time.
slide-104
SLIDE 104

Serializability and Strict Serializability

  • Common in databases, will deal with in a few classes.
  • Basic extension: consider multiple operations at a time rather than one operation.
  • Serializability: Multiple operations occur in some order.
  • Make it appear like a group of operations committed at the same time.
  • Strict Serializability: Serializability + require everything is real time.
  • Hard to implement in practice (without giving up on performance).
slide-105
SLIDE 105

Two Core Ideas

  • Reasoning about concurrent operations.
  • Building concurrent data structures from others.
slide-106
SLIDE 106

How to enforce a consistency model?

slide-107
SLIDE 107

How to Enforce a Consistency Model?

  • In almost all cases control two things:
slide-108
SLIDE 108

How to Enforce a Consistency Model?

  • In almost all cases control two things:
  • When does some change (due to an operation) become visible?
slide-109
SLIDE 109

How to Enforce a Consistency Model?

  • In almost all cases control two things:
  • When does some change (due to an operation) become visible?
  • When is a process allowed to take a step?
slide-110
SLIDE 110

Building a Linearizable Queue

  • Need to ensure linearizability.
slide-111
SLIDE 111

Building a Linearizable Queue

  • Need to ensure linearizability.
  • Need to ensure concurrent processes do not see corrupted data.
slide-112
SLIDE 112

Building a Linearizable Queue

  • Need to ensure linearizability.
  • Need to ensure concurrent processes do not see corrupted data.

type CQueue struct { l *sync.Mutex q Queue } func (q *CQueue) Enque(val) ... { q.l.Lock() defer q.l.Unlock() return q.q.Enque(val) } func (q * CQueue) Deque(val) ... { q.l.Lock() defer q.l.Unlock() return q.q.Dequeue() }

slide-113
SLIDE 113

Building a Linearizable Queue

type CQueue struct { back: int32 items: []*Item } func (q *CQueue) Enq(v: Item) { i := atomic.AddInt32(&q.back, 1) i = i - 1 atomic.StorePointer(&v, &q.items[i]) } func (q *CQueue) Deq() { for { range := atomic.LoadInt32(&q.back) for i = 0; i < range; i++ { x := atomic.SwapPointer( &q.items[i], nil) if x != nil { return *x } } } }

slide-114
SLIDE 114

Building a Linearizable Queue

slide-115
SLIDE 115

Building a Linearizable Queue

  • Are both queues correct?
  • Why prefer one or the other queue?
slide-116
SLIDE 116

CAP Theorem

slide-117
SLIDE 117

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
slide-118
SLIDE 118

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
slide-119
SLIDE 119

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
  • Based on experiences building systems at Berkeley and Inktomi.
slide-120
SLIDE 120

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
  • Based on experiences building systems at Berkeley and Inktomi.
  • Statement: For any distributed shared-data system pick two of:
slide-121
SLIDE 121

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
  • Based on experiences building systems at Berkeley and Inktomi.
  • Statement: For any distributed shared-data system pick two of:
  • Consistency
slide-122
SLIDE 122

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
  • Based on experiences building systems at Berkeley and Inktomi.
  • Statement: For any distributed shared-data system pick two of:
  • Consistency
  • Availability
slide-123
SLIDE 123

A Source of Internet Arguments

  • Eric Brewer gave a keynote at PODC 2000
  • "Towards Robust Distributed Systems"
  • Based on experiences building systems at Berkeley and Inktomi.
  • Statement: For any distributed shared-data system pick two of:
  • Consistency
  • Availability
  • Partition Tolerance
slide-124
SLIDE 124

What you read

  • An attempt to formalize this concept.
slide-125
SLIDE 125

What you read

  • An attempt to formalize this concept.
  • What is consistency?
slide-126
SLIDE 126

What you read

  • An attempt to formalize this concept.
  • What is consistency?
  • Unspecified in original talk. Gilbert and Lynch go with Linearizability.
slide-127
SLIDE 127

What you read

  • An attempt to formalize this concept.
  • What is consistency?
  • Unspecified in original talk. Gilbert and Lynch go with Linearizability.
  • What is availability?
slide-128
SLIDE 128

What you read

  • An attempt to formalize this concept.
  • What is consistency?
  • Unspecified in original talk. Gilbert and Lynch go with Linearizability.
  • What is availability?
  • System should respond to every request.
slide-129
SLIDE 129

What you read

  • An attempt to formalize this concept.
  • What is consistency?
  • Unspecified in original talk. Gilbert and Lynch go with Linearizability.
  • What is availability?
  • System should respond to every request.
  • What is partition tolerance?
slide-130
SLIDE 130

What you read

  • An attempt to formalize this concept.
  • What is consistency?
  • Unspecified in original talk. Gilbert and Lynch go with Linearizability.
  • What is availability?
  • System should respond to every request.
  • What is partition tolerance?
  • System should continue to operate despite network partitions.
slide-131
SLIDE 131

Indistinguishability

  • A common proof technique in distributed systems.

Alice Bob

slide-132
SLIDE 132

Indistinguishability

  • A common proof technique in distributed systems.

write(x = 2)

Alice Bob

slide-133
SLIDE 133

Indistinguishability

  • A common proof technique in distributed systems.

write(x = 2) write(x = 2)

Alice Bob

slide-134
SLIDE 134

Indistinguishability

  • A common proof technique in distributed systems.

write(x = 2) write(x = 2) get(x)

Alice Bob

slide-135
SLIDE 135

Indistinguishability

  • A common proof technique in distributed systems.

Alice Bob

slide-136
SLIDE 136

Indistinguishability

  • A common proof technique in distributed systems.

get(x)

Alice Bob

slide-137
SLIDE 137

Indistinguishability

  • A common proof technique in distributed systems.

get(x)

Alice Bob Alice Bob

slide-138
SLIDE 138

Indistinguishability

  • A common proof technique in distributed systems.

get(x)

Alice Bob

write(x = 2)

Alice Bob

slide-139
SLIDE 139

Indistinguishability

  • A common proof technique in distributed systems.

get(x)

Alice Bob

write(x = 2) get(x)

Alice Bob

slide-140
SLIDE 140

Fair Schedules

  • What is a fair schedule?
slide-141
SLIDE 141

Fair Schedules

  • What is a fair schedule?
  • Concern about what packets are dropped or lost.
slide-142
SLIDE 142

Fair Schedules

  • What is a fair schedule?
  • Concern about what packets are dropped or lost.
  • Could choose to only drop packets of a certain type or from a certain node.
slide-143
SLIDE 143

Fair Schedules

  • What is a fair schedule?
  • Concern about what packets are dropped or lost.
  • Could choose to only drop packets of a certain type or from a certain node.
  • Fairness means that any message should have a chance to go through.
slide-144
SLIDE 144

Fair Schedules

  • What is a fair schedule?
  • Concern about what packets are dropped or lost.
  • Could choose to only drop packets of a certain type or from a certain node.
  • Fairness means that any message should have a chance to go through.
  • Precise statement:
slide-145
SLIDE 145

Fair Schedules

  • What is a fair schedule?
  • Concern about what packets are dropped or lost.
  • Could choose to only drop packets of a certain type or from a certain node.
  • Fairness means that any message should have a chance to go through.
  • Precise statement:
  • If a node sends a message infinitely often, it must be received infinitely often.
slide-146
SLIDE 146

Why Does Fairness Matter Here?

slide-147
SLIDE 147

Partial Synchrony

  • Meant to provide a more accurate model of the network in reality.
slide-148
SLIDE 148

Partial Synchrony

  • Meant to provide a more accurate model of the network in reality.
  • Networks are not always evil, not always dropping or loosing packets.
slide-149
SLIDE 149

Partial Synchrony

  • Meant to provide a more accurate model of the network in reality.
  • Networks are not always evil, not always dropping or loosing packets.
  • Originally proposed by Dwork, Lynch and Stockmeyer
slide-150
SLIDE 150

Partial Synchrony

  • There are bounds on message delay and processing time.
slide-151
SLIDE 151

Partial Synchrony

  • There are bounds on message delay and processing time.
  • Bounds are not known a-priori.
slide-152
SLIDE 152

Partial Synchrony

  • There are bounds on message delay and processing time.
  • Bounds are not known a-priori.
  • After some finite period of time (globally) these bounds hold.
slide-153
SLIDE 153

Partial Synchrony

  • There are bounds on message delay and processing time.
  • Bounds are not known a-priori.
  • After some finite period of time (globally) these bounds hold.
  • When is not known a-priori.
slide-154
SLIDE 154

Partial Synchrony

  • There are bounds on message delay and processing time.
  • Bounds are not known a-priori.
  • After some finite period of time (globally) these bounds hold.
  • When is not known a-priori.
  • Seemingly adds very little information to the system but enables algorithms.
slide-155
SLIDE 155

Why does partial synchrony help here?

slide-156
SLIDE 156

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
slide-157
SLIDE 157

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
  • Prefer availability over consistency.
slide-158
SLIDE 158

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
  • Prefer availability over consistency.
  • Also helps performance: possibly respond without blocking.
slide-159
SLIDE 159

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
  • Prefer availability over consistency.
  • Also helps performance: possibly respond without blocking.
  • Adopted by datastores like MongoDB, CouchDB, etc.
slide-160
SLIDE 160

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
  • Prefer availability over consistency.
  • Also helps performance: possibly respond without blocking.
  • Adopted by datastores like MongoDB, CouchDB, etc.
  • One of the hallmarks of the NoSQL movement.
slide-161
SLIDE 161

Weaker Consistency Models

  • In the last decade trends towards weaker consistency models.
  • Prefer availability over consistency.
  • Also helps performance: possibly respond without blocking.
  • Adopted by datastores like MongoDB, CouchDB, etc.
  • One of the hallmarks of the NoSQL movement.
  • Look at a couple of these weaker consistency models here.
slide-162
SLIDE 162

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

slide-163
SLIDE 163

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell

slide-164
SLIDE 164

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch?

slide-165
SLIDE 165

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch? B:Taco Bell sux

slide-166
SLIDE 166

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch? B:Taco Bell sux B:Taco Bell sux

slide-167
SLIDE 167

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch? B:Taco Bell sux B:Taco Bell sux C:Agreed

slide-168
SLIDE 168

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch? B:Taco Bell sux B:Taco Bell sux C:Agreed C:Agreed

slide-169
SLIDE 169

Eventual Consistency

  • Operations eventually become visible.
  • No ordering guarantees beyond that.

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell A: Taco Bell B: Lunch? B:Taco Bell sux B:Taco Bell sux C:Agreed C:Agreed B:Taco Bell sux

slide-170
SLIDE 170

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

slide-171
SLIDE 171

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell

slide-172
SLIDE 172

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell?

slide-173
SLIDE 173

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell? B:Taco Bell sux

slide-174
SLIDE 174

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell? B:Taco Bell sux B:Taco Bell sux

slide-175
SLIDE 175

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell? B:Taco Bell sux B:Taco Bell sux C:Agreed

slide-176
SLIDE 176

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell? B:Taco Bell sux B:Taco Bell sux C:Agreed B:Taco Bell sux

slide-177
SLIDE 177

Causal Consistency

  • Operations eventually become visible.
  • Order preserves causality

B: Lunch? A: Taco Bell?

A B C

B: Lunch? A: Taco Bell B: Lunch A: Taco Bell? B:Taco Bell sux B:Taco Bell sux C:Agreed C:Agreed B:Taco Bell sux

slide-178
SLIDE 178

Relaxing Consistency

  • Pros:
slide-179
SLIDE 179

Relaxing Consistency

  • Pros:
  • Availability, performance.
slide-180
SLIDE 180

Relaxing Consistency

  • Pros:
  • Availability, performance.
  • Cons:
slide-181
SLIDE 181

Relaxing Consistency

  • Pros:
  • Availability, performance.
  • Cons:
  • Hard to program? Hard to reason about correctness?
slide-182
SLIDE 182

Relaxing Consistency

  • Pros:
  • Availability, performance.
  • Cons:
  • Hard to program? Hard to reason about correctness?
  • Research Questions:
slide-183
SLIDE 183

Relaxing Consistency

  • Pros:
  • Availability, performance.
  • Cons:
  • Hard to program? Hard to reason about correctness?
  • Research Questions:
  • When is a given consistency model appropriate?
slide-184
SLIDE 184

Relaxing Consistency

  • Pros:
  • Availability, performance.
  • Cons:
  • Hard to program? Hard to reason about correctness?
  • Research Questions:
  • When is a given consistency model appropriate?
  • How to improve developer productivity given weaker consistency models?
slide-185
SLIDE 185

Conclusion

  • Consistency models are a way to reason about when events take effect.
  • Both necessary when building systems and when reasoning about systems.