Shared Memory Algorithms Overview Prof R Guerraoui Assistant

  • Slides: 59
Download presentation
Shared Memory Algorithms (Overview) Prof R. Guerraoui Assistant M. Kapalka Distributed Programming Laboratory ©

Shared Memory Algorithms (Overview) Prof R. Guerraoui Assistant M. Kapalka Distributed Programming Laboratory © R. Guerraoui 1

In short This course introduces a theory of robust concurrent computing 2

In short This course introduces a theory of robust concurrent computing 2

Major chip manufacturers have recently announced what is perceived as a major paradigm shift

Major chip manufacturers have recently announced what is perceived as a major paradigm shift in computing: Multiprocessors vs faster processors May be Moore was wrong… 3

The clock speed of a processor cannot be increased without overheating But More and

The clock speed of a processor cannot be increased without overheating But More and more processors can fit in the same space 4

Speed will be achieved by having several processors work on independent parts of a

Speed will be achieved by having several processors work on independent parts of a task But the processors would occasionally need to pause and synchronize 5

Why synchronize? But If the task is indeed common, then pure parallelism is usually

Why synchronize? But If the task is indeed common, then pure parallelism is usually impossible and, at best, inefficient 6

Concurrent processes Shared object 7

Concurrent processes Shared object 7

Concurrent computing for the masses Forking processes might become more frequent But Concurrent accesses

Concurrent computing for the masses Forking processes might become more frequent But Concurrent accesses to shared objects might become more problematic 8

Locking (mutual exclusion) Difficult: 50% of the bugs reported in Java come from the

Locking (mutual exclusion) Difficult: 50% of the bugs reported in Java come from the use of « synchronized » Fragile: a process holding a lock prevents all others from progressing 9

Locked object One process at a time 10

Locked object One process at a time 10

Processes are asynchronous Page faults, pre-emptions, failures, cache misses, … A process can be

Processes are asynchronous Page faults, pre-emptions, failures, cache misses, … A process can be delayed by millions of instructions … 11

Alternative to locking? 12

Alternative to locking? 12

Wait-free atomic objects Wait-freedom: every process that invokes an operation eventually returns from the

Wait-free atomic objects Wait-freedom: every process that invokes an operation eventually returns from the invocation (robust … unlike locking) Atomicity: every operation appears to execute instantaneously (as if the object was locked…) 13

In short This course shows how to wait-free implement high-level atomic objects out of

In short This course shows how to wait-free implement high-level atomic objects out of more primitive base objects 14

Concurrent processes Shared object 15

Concurrent processes Shared object 15

This course Theoretical No specific theoretic background Written exam on Feb 6 th 16

This course Theoretical No specific theoretic background Written exam on Feb 6 th 16

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 17

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 17

Processes § We assume a finite set of processes § Processes are denoted by

Processes § We assume a finite set of processes § Processes are denoted by p 1, . . p. N or p, q, r § Processes have unique identities and know each other (unless explicitely stated otherwise) 18

Processes are sequential units of computations Unless explicitely stated otherwise, we make no assumption

Processes are sequential units of computations Unless explicitely stated otherwise, we make no assumption on process (relative) speed 19

Processes p 1 p 2 p 3 20

Processes p 1 p 2 p 3 20

Processes A process either executes the algorithm assigned to it or crashes A process

Processes A process either executes the algorithm assigned to it or crashes A process that crashes does not recover (in the context of the considered computation) A process that does not crash in a given execution (computation or run) is called correct (in that execution) 21

Processes p 1 p 2 crash p 3 22

Processes p 1 p 2 crash p 3 22

On objects and processes Processes execute local computation or access shared objects through their

On objects and processes Processes execute local computation or access shared objects through their operations Every operation is expected to return a reply 23

Processes operation p 1 operation p 2 operation p 3 24

Processes operation p 1 operation p 2 operation p 3 24

On objects and processes Sequentiality means here that, after invoking an operation op 1

On objects and processes Sequentiality means here that, after invoking an operation op 1 on some object O 1, a process does not invoke a new operation (on the same or on some other object) until it receives the reply for op 1 Remark. Sometimes we talk about operations when we should be talking about operation invocations 25

Processes operation p 1 operation p 2 operation p 3 26

Processes operation p 1 operation p 2 operation p 3 26

Atomicity We mainly focus in this course on how to implement atomic objects Atomicity

Atomicity We mainly focus in this course on how to implement atomic objects Atomicity means that every operation appears to execute at some indivisible point in time (called linearization point) between the invocation and reply time events 27

Atomicity operation p 1 operation p 2 operation p 3 28

Atomicity operation p 1 operation p 2 operation p 3 28

Atomicity operation p 1 operation p 2 operation p 3 29

Atomicity operation p 1 operation p 2 operation p 3 29

Wait-freedom We mainly focus in this course on waitfree implementations An implementation is wait-free

Wait-freedom We mainly focus in this course on waitfree implementations An implementation is wait-free if any correct process that invokes an operation eventually gets a reply, no matter what happens to the other processes (crash or very slow) 30

Wait-freedom operation p 1 p 2 p 3 31

Wait-freedom operation p 1 p 2 p 3 31

Wait-freedom conveys the robustness of the implementation With a wait-free implementation, a process gets

Wait-freedom conveys the robustness of the implementation With a wait-free implementation, a process gets replies despite the crash of the n-1 other processes Note that this precludes implementations based on locks (mutual exclusion) 32

Wait-freedom operation p 1 p 2 crash p 3 crash 33

Wait-freedom operation p 1 p 2 crash p 3 crash 33

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 34

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 34

Motivation Most synchronization primitives (problems) can be precisely expressed as atomic objects (implementations) Studying

Motivation Most synchronization primitives (problems) can be precisely expressed as atomic objects (implementations) Studying how to ensure robust synchronization boils down to studying wait-free atomic object implementations 35

Example 1 The reader/writer synchronization problem corresponds to the register object Basically, the processes

Example 1 The reader/writer synchronization problem corresponds to the register object Basically, the processes need to read or write a shared data structure such that the value read by a process at a time t, is the last value written before t 36

Register A register has two operations: read() and write() We assume that a register

Register A register has two operations: read() and write() We assume that a register contains an integer for presentation simplicity, i. e. , the value stored in the register is an integer, denoted by x (initially 0) 37

Sequential specification read() return(x) write(v) x <- v; return(ok) 38

Sequential specification read() return(x) write(v) x <- v; return(ok) 38

Atomicity? write(1) - ok p 1 read() - 2 p 2 write(2) - ok

Atomicity? write(1) - ok p 1 read() - 2 p 2 write(2) - ok p 3 39

Atomicity? write(1) - ok p 1 read() - 2 p 2 write(2) - ok

Atomicity? write(1) - ok p 1 read() - 2 p 2 write(2) - ok p 3 40

Atomicity? write(1) - ok p 1 read() - 1 p 2 write(2) - ok

Atomicity? write(1) - ok p 1 read() - 1 p 2 write(2) - ok p 3 41

Atomicity? write(1) - ok p 1 read() - 1 p 2 write(2) - ok

Atomicity? write(1) - ok p 1 read() - 1 p 2 write(2) - ok p 3 42

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 1

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 1 p 3 43

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 0

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 0 p 3 44

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0 p 3 45

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0 p 3 46

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0

Atomicity? write(1) - ok p 1 read() - 0 p 2 read() - 0 p 3 47

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 0

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 0 p 3 48

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 1

Atomicity? write(1) - ok p 1 read() - 1 p 2 read() - 1 p 3 49

Example 2 The producer/consumer synchronization problem corresponds to the queue object Producer processes create

Example 2 The producer/consumer synchronization problem corresponds to the queue object Producer processes create items that need to be used by consumer processes An item cannot be consumed by two processes and the first item produced is the first consumed 50

Queue A queue has two operations: enqueue() and dequeue() We assume that a queue

Queue A queue has two operations: enqueue() and dequeue() We assume that a queue internally maintains a list x which exports operation appends() to put an item at the end of the list and remove() to remove an element from the head of the list 51

Sequential specification dequeue() if(x=0) then return(nil); else return(x. remove()) enqueue(v) x. append(v); return(ok) 52

Sequential specification dequeue() if(x=0) then return(nil); else return(x. remove()) enqueue(v) x. append(v); return(ok) 52

Atomicity? enq(x) - ok p 1 enq(y) - ok deq() - y p 2

Atomicity? enq(x) - ok p 1 enq(y) - ok deq() - y p 2 deq() - x p 3 53

Atomicity? enq(x) - ok p 1 enq(y) - ok deq() - y p 2

Atomicity? enq(x) - ok p 1 enq(y) - ok deq() - y p 2 deq() - x p 3 54

Atomicity? enq(x) - ok p 1 deq() - y p 2 enq(y) - ok

Atomicity? enq(x) - ok p 1 deq() - y p 2 enq(y) - ok p 3 55

Atomicity? enq(x) - ok p 1 deq() - y p 2 enq(y) - ok

Atomicity? enq(x) - ok p 1 deq() - y p 2 enq(y) - ok p 3 56

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 57

Roadmap Model Processes and objects Atomicity and wait-freedom Examples Content 57

Content (1) Implementing registers (2) The power & limitation of registers (3) Universal objects

Content (1) Implementing registers (2) The power & limitation of registers (3) Universal objects & synchronization number (4) The power of time & failure detection (5) Tolerating failure prone objects (6) Anonymous implementations (7) Transaction memory 58

In short This course shows how to wait-free implement high-level atomic objects out of

In short This course shows how to wait-free implement high-level atomic objects out of basic objects Remark. Unless explicitely stated otherwise, objects mean atomic objects and implementations are wait-free 59