Concurrency Runtime Finishing Erlang

CONCURRENCYRUNTIMEFINISHING ERLANG

ID1218 Lecture 06 2009-11-16

Christian [email protected]

Software and Computer SystemsSchool of Information and Communication

TechnologyKTH – Royal Institute of Technology

Stockholm, Sweden

mailto:[email protected]

Overview Concurrent MiniErlang

sketch how it really computes builds on MiniErlang

Analyzing runtime asymptotic complexity, big-O notation analyzing recursive functions

Wrapping up the Erlang part will return later as point for comparison

L06, 2009-11-16ID1218, Christian Schulte

2

Processes With State

L06, 2009-11-16

3

ID1218, Christian Schulte


4

Processes Receive messages

To be useful they need to maintain state changing over time

Model: process is modeled by functionstate message state


5

Process States

s0 s1 s2 …a a a

receivemessages


6

Defining a Process With State Process

how it reacts to messages how it transforms the state from which initial state it starts

Additionally process might compute by sending messages

to other processes


7

Example: Logic of a Cell Process

cell({assign,New},S) -> New;cell({access,PID},S) -> PID ! {self(),S}, S.

Captures how the process transforms state how it acts to incoming messages

A Generic Process With Stateserve(F,InS) -> receive Msg -> OutS = F(Msg,InS), serve(F,OutS) end.cellserver() -> spawn(fun () -> serve(fun cell/2,0) end). Can be started

with function that performs state transitions initial value for state


8

Making The Server Smarterserve(F,InS) -> receive kill -> void; … Msg -> OutS = F(Msg,InS), serve(F,OutS) end. Add generic functionality to server


9

A Reconfigurable Server Behavior of server defined by

generic message receipt specific state transformation plus

communication Idea: make server reconfigurable

change how state is transformed adapt state to possibly new representation


10

A Reconfigurable Serverserve(F,InS) -> receive kill -> void; {update,NewF,Adapt} -> serve(NewF,Adapt(InS)); … Msg -> OutS = F(Msg,InS), serve(F,OutS) end.


11


12

Buffered Cellsbcell({assign,V},{_,B}) -> {V,B};bcell({access,PID},{V,B}) -> PID ! {self(),V}, {V,B};bcell({save},{V,_}) -> {V,V};bcell({restore},{_,B}) -> {B,B}.

Features states {V,B} with value V and buffer B

Reconfiguring the Server> C=cellserver().…> C ! {assign,4}.…> C ! {update, fun bcell/2, fun (Old) -> {Old,0} end}.…> C ! {save}. …


13

Coordination

L06, 2009-11-16

14



15

Protocols Protocol: rules for sending and receiving

messages programming with processes

Examples broadcasting messages to group of processes choosing a process

Important properties of protocols safety liveness


16

Choosing a Process Example: choosing the best lift, connection, … More general: seeking agreement

coordinate execution

General idea: Master

send message to all slaves containing reply PID select one slave: accept all other slaves: reject

Slaves answer by replying to master PID wait for decision from master

Master: Blueprintdecide(SPs) -> Rs=collect(SPs,propose), {SP,SPr}=choose(SPs,Rs), SP ! {self(),accept}, broadcast(SPr,reject}. Generic:

collecting and broadcasting Specific:

choose single process from processes based on replies Rs


17

Slave: Blueprintslave() -> receive {M,propose} -> R=…, M ! {self(),R}, receive {M,accept} -> …; {M,reject} -> … end end


18


19

Avoiding Deadlock Master can only proceed, after all slaves

answered will not process any more messages until then receiving messages in collect

Slave can only proceed, after master answered

will not process any more messages until then What happens if multiple masters for

same slaves?


20

Deadlock

M

N

B

A

C

D

Master Slave


21

Deadlock

M

N

B

A

C

D

Master Slave


22

Deadlock

M

N

B

A

C

D

Master Slave


23

Deadlock

M

N

B

A

C

D

Master Slave

blocks!


24

Deadlock

M

N

B

A

C

D

Master Slave

blocks!

blocks!


25

Deadlock

M

N

B

A

C

D

Master Slave

blocks!

blocks!

M blocks A, waits for B N blocks B, waits for A Deadlock!!!!


26

Avoiding Deadlock Force all masters to send in order:

First A, then B, then C, … Guarantee: If A available, all others will be available difficult: what if dynamic addition and removal of lists does not work with low-latency collect

low-latency: messages can arrive in any order high-latency: receipt imposes strict order

Use an adaptor access to slaves through one single master slaves send message to single master problem: potential bottleneck


27

Adaptor

M

N

B

A

C

D

Master Slave

Adaptoradaptor() -> receive {decide,Client,PIDs} -> decide(PIDs), Client ! self(), adaptor() end.% A is PID of adaptor processndecide(A,PIDs) -> A ! {decide,self(),PIDs}, receive A -> void end.

Run single dedicated adaptor process master blocks until decision process has terminated


28

Liveness Properties Important property of concurrent programs

liveness An event/activity might fail to be live

other activities consume all CPU power message box is flooded (denial of services) activities have deadlocked …

Difficult: all possible interactions with other processes must guarantee liveness

reasoning of all possible interactions


29


30

Summary Protocols for coordinating processes Can lead to deadlocks Simple structure best Important: liveness guarantees

Process State Reconsidered

L06, 2009-11-16

31



32

Creating a Cell Processcell() -> spawn(fun cell/2,0).

Cell process initialized with zero as state


33

A Simple Taskinc(C) -> C ! {access,self()}, receive {C,N} -> C ! {assign,N+1} end.

Increment the cell’s content by one get the old value put the new value

Does this work? NO! NO! Why?


34

A Simple Task Screwed…C=cell(),P1=spawn(fun () inc(C) end),P2=spawn(fun () inc(C) end),…

We insist on result being 2! sometimes: 2 sometimes: 1

Why?


35

Execution Sketch A: Good Process 1

C receives {access,P1} value got: 0 Process 1

C receives {assign,1} value put: 1 Process 2

C receives {access,P2} value got: 1

Process 2 C receives {assign,2} value put: 2


36

Execution Sketch A: Bad Process 1

C receives {access,P1} value got: 0 Process 2

C receives {access,P2} value got: 0




37

What Is Needed We need to avoid that multiple access

and assign operations get out of order We need to combine access and assign

into one operation we can not guarantee that not interrupted we can guarantee that state is consistent we can guarantee that no other message is

processed in between operation is called atomic


38

Cell With Exchangecell({assign,New},S) -> New;cell({access,PID},S) -> PID ! {self(),S}, S;cell({exchange,PID},S) -> PID ! {self(),S}, receive {PID,NewS} -> NewS end.


39

Incrementing Rectifiedinc(C) -> C ! {exchange,self()}, receive {C,N} -> C ! {self(),N+1} end

Important aspect no message will be received in between!


40

State and Concurrency Difficult to guarantee that state is

maintained consistently in a concurrent setting

Typically needed: atomic execution of several statements together

Processes guarantee atomic execution


41

Other Approaches Atomic exchange

lowlevel hardware: test-and-set

Locks: allow only one thread in a “critical section”

monitor: use a lock together with a process generalizations to single writer/multiple reader

Locking Processes Idea that is used most often in

languages which rely on state Before state can be manipulated: lock

must be acquired for example, one lock per object

If process has acquired lock: can perform operations

If process is done, lock is released


42

A Lockable Processoutside(F,InS) -> receive {acquire,PID} -> PID ! {ok,self()}, inside(F,InS,PID) end.inside(F,InS,PID) -> receive {release,PID} -> outside(F,InS) {PID,Msg} -> inside(F,F(Msg,InS)); end.


43

Safety Properties Maintain state of processes in consistent

fashion do not violate invariants to not compute incorrect results

Guarantee safety by atomic execution exclusion of other processes ("mutual

exclusion")


44

Concurrent MiniErlang (CME)


45

Processes in CME Computation state is a collection of processes

P1 P2 … Pn every process must be reduced eventually (fairness) no order among processes (set of processes)

A process is an extended MiniErlang machineEs ; Vs ; n ; Ms

expression stack Es value stack Vs process identifier (PID) n mailbox Ms


46

CME: Values and Expressions Values now also include PIDs

V := int | [] | [ V1 | V2 ] | n PIDs cannot not appear in expressions

Expressions E := … | self() | E1 ! E2 | spawn(F)| E1 , E2 | receive C1; …; Cn end

InstructionsCONS, CALL, SEND


47

Sequential CompositionE1,E2Es ; Vs ; n ; Ms Pr → E1E2Es ; Vs ; n ; Ms Pr

Decompose into individual statements obey order of statements

To be read: pick fairly any process that matches this pattern


48

Self PIDself()Es ; Vs ; n ; Ms Pr → Es ; nVs ; n ; Ms Pr

Pushes process' own PID on the value stack


49

Process Spawningspawn(F)Es ; Vs ; n ; Ms Pr → Es ; mVs ; n ; Ms

F(); ; m ; Pr

Create new process with expression stack that executes call to F an empty value stack a fresh (not used elsewhere) PID m an empty mailbox


50

Process Termination; V ; n ; Ms Pr → Pr

Delete process without expression to be evaluated

single value on stack is ignored


51

Message SendingE1!E2Es ; Vs ; n ; Ms Pr → E1E2SENDEs ; Vs ; n ; Ms Pr

First evaluate destination, then message After that perform message sending


52

SEND InstructionSENDEs ; V1mVs ; n ; Ms Es’ ; Vs’ ; m ; Ms’ Pr

→ Es ; V1Vs ; n ; Ms Es’ ; Vs’ ; m ; Ms’V1 Pr

Instruction sends and evaluates to message Semantics is stronger than Erlang behavior

realistic: model messages in transit with FIFO


53

Message Selectionselect(C1; …; Cn, MMs, Ns) = s(Bi),

NsMs if Ci = Hi -> Bi is first matching clause,

match(Hi, M)=s select(C1; …; Cn, MMs, Ns) =

select(C1; …; Cn, Ms, NsM) if no clause matches

select(C1; …; Cn, , Ns) = no

Traverses messages in mailbox in order constructs mailbox with all messages but

received one


54

Message Receiptreceive C1; …; Cn endEs ; Vs ; n ; Ms

Pr → EEs ; Vs ; n ; Ns Pr

if select(C1; …; Cn, Ms, ) = E, Ns

Process can only receive if matching message is found


55

CME Machine Initial configuration:

single process with expression we want to evaluate on expression stack

Final configuration: no process can be reduced not common, computations continue forever


56

ME and CME Differences Expressions in ME can be replaced by

the value they can be evaluated to declarative: independent reasoning referential transparency

Not true in CME message sending as side-effect concurrently coordinating: reason on

interaction


57

Runtime Efficiency

L06, 2009-11-16

58



59

What Are the Questions? Runtime efficiency

what is it we are interested in? why are we interested? how to make statements on runtime and

memory?

Clearly “faster” is better we have to know how fast our programs

compute we have to know how much memory our

programs require we have to know how “good” a program is


60

Statements on Runtime Run your program for some example

data sets on some computer, make a statement

statement valid, if data set gets larger? statement valid, if executed on different

computer? statement valid, if executed on same computer

but slightly different configuration?

Testing is insufficient!


61

Runtime Guarantees Testing can never yield a guarantee on

runtime!

We need a form to express runtime guarantees

capture size of input data capture different computers/configurations


62

Runtime Guarantees Express runtime in relation to input size

T(n) runtime function where n is size of input

for example integers argument lists length of list


63

Runtime Guarantees We need to ignore marginal difference

between runtime functions

difference for small input sizesonly consider for n ≥ n0

difference by constantc1 T(n) same as c2 T(n)


64

Asymptotic Complexity Asymptotic complexity is such a runtime

guarantee: bestupper bound

on runtimeup to a constant factorfor sufficiently large inputs

Discuss runtime by using “big-oh” notation


65

Big-Oh Notation Assume

T(n) runtime, n size of input f(n) function on non-negative integers

T(n) is of O(f(n)) “T(n) is of order f(n)”iff T(n) c f(n) for all n≥n0

for some c (whatever computer) for some n0 (sufficiently large)


66

Big-Oh Notation

T(n) is of O(f(n)) “T(n) is of order f(n)”iff T(n) c f(n) for all n≥n0

for some c (whatever computer) for some n0 (sufficiently large)

cn

n0 n

T(n)f(n) = n, c=2


67

Big-Oh Notation T(n) is of O(f(n)) sometimes written as

T(n) = O(f(n)) T(n) O(f(n))

Examples T(n) = 4n + 42 is O(n) T(n) = 5n + 42 is O(n) T(n) = 7n + 11 is O(n) T(n) = 4n + n3 is O(n3) T(n) = n100 + 2n + 8 is O(2n)


68

Big-Oh Notation Often one just says for

O(n) linear complexity O(n2) quadratic complexity O(n3) cubic complexity O(log n) logarithmic complexity O(2n) exponential complexity


69

Summary Formulate statements on runtime as

runtime guaranteesasymptotic complexity

for large input independent of computer

Expressed in big-oh notation abstracts away behavior of function for small

numbers abstracts away constants captures asymptotic behavior of functions

Determining Complexity

L06, 2009-11-16

70



71

Approach Take MiniErlang program Take execution time for each expression Give equations for runtime of functions Solve equations Determine asymptotic complexity


72

Simplification Here We will only consider programs with one

function Generalization to many functions

straightforward complication: solving equation


73

Execution Times for Expressions

Give inductive definition based on function definition and structure of expressions

Function definition pattern matching and guards

Simple expression values and list construction

More involved expression function call recursive function call leads to recursive

equation often called: recurrence equation


74

Execution Time: T(E) Value

T(V) = cvalue List construction

T([E1|E2]) = ccons + T(E1) + T(E2)

Time T(E) needed for executing expression E

how MiniErlang machine executes E


75

Execution Time: T(E) Value

T(V) = c List construction

T([E1|E2]) = c + T(E1) + T(E2)

Time T(E) needed for executing expression E

how MiniErlang machine executes E

to ease notation, just forget subscript


76

Function Call For a function F define a function

TF(n) for its runtimeand determine

size of input for call to F input for a function


77

Function CallT(F(E1, ..., Ek)) = ccall + T(E1) + ... + T(Ek)

+ TF(size(IF({1, ..., k})))

input arguments IF({1, ..., k}) input arguments for F

size size(IF({1, ..., k}))size of input for F

Function Definition Assume function F defined by clauses

H1 -> B1; …; Hk -> Bk.

TF(n) = cselect + max { T(B1), …, T(Bk) }


78


79

Example: app/2app([],Ys) -> Ys;app([X|Xr],Ys) -> [X|app(Xr,Ys)].

What do we want to computeTapp(n)

Knowledge needed input argument first argument size function length of list


80

Computing Tapp =Ta

let’s use the whiteboard…


81

Append: Recurrence Equation Analysis yields

Tapp(0) = c1

Tapp(n) = c2 + Tapp(n-1) Solution to recurrence is

Tapp(n) = c1 + c2 n Asymptotic complexity

Tapp(n) is of O(n) “linear complexity”


82

Recurrence Equations Analysis in general yields a system

T(n) defined in terms of T(m1), …, T(mk)for m1, …, mk < n

T(0), T(1), … values for certain n

Possibilities solve recurrence equation (difficult in general) lookup asymptotic complexity for common case

L06, 2009-11-16 ID1218, Christian Schulte 83

Common Recurrence Equations

T(n) Asymptotic Complexityc + T(n–1) O(n)

c1 + c2n + T(n–1) O(n2)

c + T(n/2) O(log n)

c1 + c2n + T(n/2) O(n)

c + 2T(n/2) O(n)

c + 2T(n-1) O(2n)

c1 + c2n + T(n/2) O(n log n)

Example: Naïve Reverse rev([]) -> [];rev([X|Xr]) -> app(rev(Xr),[X]).

Analysis yieldsTrev(0) = c1

Trev(n) = c2 + Tapp(n-1) + Trev(n-1)= c2 + c3(n-1) + Trev(n-1)

Asymptotic complexityTrev(n) is of O(n2) “quadratic complexity”


84


85

What Is to be Done? Size functions and input functions Recurrence equation Finding asymptotic complexity

…understanding of programs might be

necessary…


86

Obs! Making computations iterative can

change runtime! Can improve:

Naïve reverse reverseO(n2) O(n)

Can be worse:appending lists appending lists

O(n) O(n2)


87

Judging Asymptotic Complexity What does it mean?

good/bad? even optimal?

Consider size of computed output if size is of same order: perfect? otherwise:

O(n log n) is very good (optimal for sorting) check book on algorithms

Very difficult problem!


88

Hard Problems Computer science is tough business Most optimization, combinatorial

problems are hard (non-tractable) problems

Graph coloring minimal number of colors no connected node has same color used in: compilation, frequency allocation, …

Travelling salesman


89

Hard Problems NP problems: easy (polynomial

complexity) for checking whether a certain candidate is a solution to problem

much harder: finding a solution

NP-complete problems: as hard as any other NP-complete problem

strong suspicion: no polynomial algorithm for finding a solution exists

examples: graph coloring, satisfiability testing, cryptography, …


90

Summary: Runtime Efficiency Asymptotic complexity gives runtime

guarantee abstract from constants for all possible input given in Big-Oh notation

Computing asymptotic complexity

Think about meaning of asymptotic complexity

Summary: Part 1

L06, 2009-11-16

91


Functional Programming in Erlang

Functions defined by clauses clauses have patterns and guards

Execution evaluates expressions declarative

Expressions: values and function call Pattern matching for clause selection

powerful for symbolic computation


92

MiniErlang Model for functional Erlang that captures

memory consumption in particular stack space for function calls

MiniErlang machine gives operational semantics

Identifies iterative computations run with constant stack space captures tail recursion

Model for runtime analysis


93

Functional Programming Techniques

Pattern matching for execution control Accumulators

make more functions tail recursive Higher-order functions

pass functions as parameters separate generic from specific aspects


94

Concurrent Programming in Erlang

Message-passing between concurrent processes

fair execution of processes fully buffered message delivery processes with identity

Programmable receipt of messages in particular: pick messages by sending process with possibility of timeout


95

Concurrent Programming Techniques

Sending messages: asynchronous, synchronous

Communication patterns asynchronous broadcasting synchronous broadcasting: low latency versus order choosing processes

Avoiding deadlocks order recipients, introduce concurrency adaptors

Essential properties liveness safety


96

Other Things in Erlang Exception handling Distributed programming Fault-tolerant programming


97

Date post:	23-Feb-2016
Category:	Documents
Upload:	darcie
View:	57 times
Download:	4 times

Concurrency Runtime Finishing Erlang

Documents