1. ITERATIVE COMPUTATIONS CONCURRENCY ID1218 Lecture 042009-11-04 Christian Schulte cschulte@kth.se Software and Computer Systems School of Information and Communication Technology KTH – Royal Institute of Technology Stockholm, Sweden

2. A Fourth Look L04, 2009-11-04ID1218, Christian Schulte 2

3. A Better Length? L04, 2009-11-04ID1218, Christian Schulte l([]) -> 0; l([_|Xr]) -> 1+l(Xr). l([],N) -> N; l([_|Xr],N) -> l(Xr,N+1).  Two different functions: l/1 and l/2  Which one is better? 3

4. Running l/1 l([1,2,3]) ;  → [1,2,3]  CALL(l/1) ;  → CALL(l/1) ; [1,2,3] → 1+l([2,3]) ;  → 1  l([2,3])  ADD ;  → l([2,3])  ADD ; 1 → [2,3]  CALL(l/1)  ADD ; 1 → CALL(l/1)  ADD ; [2,3]  1 → 1+l([3])  ADD ; 1 → 1  l([3])  ADD  ADD ; 1 → l([3])  ADD  ADD ; 1  1 → …  requires stack space in the length of list L04, 2009-11-04ID1218, Christian Schulte 4

5. Running l/2 l([1,2,3],0) ;  → [1,2,3]  0  CALL(l/2) ;  → 0  CALL(l/2) ; [1,2,3] → CALL(l/2) ; 0  [1,2,3] → l([2,3],0+1) ;  → [2,3]  0+1  CALL(l/2) ;  → 0+1  CALL(l/2) ; [2,3] → 0  1  ADD  CALL(l/2) ; [2,3] → 1  ADD  CALL(l/2) ; 0  [2,3] → ADD  CALL(l/2) ; 1  0  [2,3] → CALL(l/2) ; 1  [2,3] → l([3],1+1) ;  → …  requires constant stack space! L04, 2009-11-04ID1218, Christian Schulte 5

6. Appending Two Lists L04, 2009-11-04ID1218, Christian Schulte app([],Ys) -> Ys; app([X|Xr],Ys) -> [X|app(Xr,Ys)].  How much memory needed: easy!  Stack space… in the length of the first list CONS accumulate on the stack 6

7. L04, 2009-11-04ID1218, Christian Schulte Iterative Computations  Iterative computations run with constant stack space  Make use of last optimization call correspond to loops essentially  Tail recursive procedures are computed by iterative computations 7

8. Concurrency L04, 2009-11-04 8 ID1218, Christian Schulte

9. L04, 2009-11-04ID1218, Christian Schulte 9 The World Is Concurrent!  Concurrent programs several activities execute simultaneously (concurrently)  Most of the software you use is concurrent operating system: IO, user interaction, many processes, … web browser, Email client, Email server, … telephony switches handling many calls …

10. L04, 2009-11-04ID1218, Christian Schulte 10 Why Should We Care?  Software must be concurrent… … for many application areas  Concurrency can be helpful for constructing programs organize programs into independent parts concurrency allows to make them independent with respect to how they execute essential: how do concurrent programs interact?

11. L04, 2009-11-04ID1218, Christian Schulte 11 Concurrent Programming Is Easy…  Erlang has been designed to be very good at concurrency…  Essential for concurrent programming here message passing very simple interaction between concurrent programs light-weight processes no shared data structures independence

12. Concurrency in Erlang  Concurrent programs are composed of communicating processes each process has a unique id: PID processes are spawned to execute functions send messages to PIDs receive messages messages are Erlang data structures  Erlang processes are not OS processes one Erlang OS process can host lots of Erlang processes create by spawning they are independent of the underlying OS L04, 2009-11-04ID1218, Christian Schulte 12

13. Creating Processes  Spawning a process: takes a function as input creates a new concurrently running process executing the function returns the PID of the newly created process L04, 2009-11-04ID1218, Christian Schulte 13

14. Our First Process loop() -> receive kill -> io:format("Aargh: dead...~n"); Other -> io:format("Yummy: ~p~n",[Other]), loop() end. L04, 2009-11-04ID1218, Christian Schulte 14

15. Running the Process > P=spawn(fun loop/0). > P ! apple. … Yummy: apple > P ! bogey. … Yummy: bogey > P ! kill. … Aaargh: dead > P ! ham. … L04, 2009-11-04ID1218, Christian Schulte 15

16. Processes Run Forever…  Why does process not run out of memory property of loop/0 L04, 2009-11-04ID1218, Christian Schulte 16

17. Primitives  Creating processes spawn(F) for function value F spawn(M,F,As) for function F in module M with argument list As  Sending messages PID ! message  Receiving messages receive … end with clauses  Who am I? self() returns the PID of the current process L04, 2009-11-04ID1218, Christian Schulte 17

18. Processes  Each process has a mailbox incoming messages are stored in order of arrival sending puts message in mailbox  Processes are executed fairly if a process can receive a message or compute… …eventually, it will It will pretty soon… Simple priorities available (low) L04, 2009-11-04ID1218, Christian Schulte 18

19. Message Sending  Message sending P ! M is asynchronous the sender does not wait until message has been processed continues execution immediately evaluates to M  When a process sends messages M1 and M2 to same PID, they arrive in order in mailbox FIFO ordering  When a process sends messages M1 and M2 to different processes, order of arrival is undefined L04, 2009-11-04ID1218, Christian Schulte 19

20. Message Receipt  Only receive inspects mailbox all messages are put into the mailbox  Messages are processed in order of arrival that is, receive processes mailbox in order  If the receive statement has a matching clause for the first message remove message and execute clause always choose the first matching clause  Otherwise, continue with next message  Unmatched messages are kept in original order L04, 2009-11-04ID1218, Christian Schulte 20

21. Receive Example 1. receive c -> … end 2. receive d -> …; b -> … end 3. receive M -> … end L04, 2009-11-04ID1218, Christian Schulte 21 a b c d a b d a d d mailbox head 1.2.3.

22. Receiving Multiple Messages seq() -> receive a -> receive b -> … end; c -> … end.  With other words: processes can use different receive statements  What does it mean is a sent before b ? is a received before b ? L04, 2009-11-04ID1218, Christian Schulte 22

23. Receive With Timeouts receive … after Time -> Expr end  If no matching message arrived within Time milliseconds, evaluate Expr  If only after clause present, process sleeps for Time milliseconds L04, 2009-11-04ID1218, Christian Schulte 23

24. Flushing the Mailbox flush() -> receive _ -> flush() after 0 -> true end. L04, 2009-11-04ID1218, Christian Schulte 24

25. Priority Receipt priority() -> receive alarm -> … after 0 -> receive M -> …, priority() end end. L04, 2009-11-04ID1218, Christian Schulte 25

26. Timed Repeater start(T,F) -> spawn(fun() -> rep(T,F) end). stop(PID) -> PID ! stop. rep(T,F) -> receive stop -> true after T -> F(), rep(T,F) end. L04, 2009-11-04ID1218, Christian Schulte 26

27. Different Message Types receive {a, … } -> … ; {b, … } -> … … end  Use tuples as messages first field of tuple describes message type L04, 2009-11-04ID1218, Christian Schulte 27

28. Client Server Architectures L04, 2009-11-04 28 ID1218, Christian Schulte

29. Client Server  Single server processing requests wait for request perform request reply to request (ok or result)  Multiple clients sending requests send request wait for reply  Very common architecture WWW, RPC, RMI, … example: RPC L04, 2009-11-04ID1218, Christian Schulte 29

30. How to Reply: RPC  Server must know how to reply to client client sends request… …plus its own PID PID of process available via self()  After server has fulfilled request sends back reply to sender's PID  RPC is synchronous client must wait until reply received L04, 2009-11-04ID1218, Christian Schulte 30

31. RPC Server serve() -> receive {Client,Request} -> Response = process(Request), Client ! Response, serve() end. L04, 2009-11-04ID1218, Christian Schulte 31

32. RPC Client rpc(Server,Request) -> Server ! {self(), Request}, receive Response -> Response end.  This is easy… but wrong… assumption: first message in mailbox is from server but: can be from anybody! L04, 2009-11-04ID1218, Christian Schulte 32

33. Who Talks To Me?  If we only want to receive messages from process PID, messages must include PID  Sending P ! {self(), … }  Receipt PID= …, receive {P,…} when P==PID -> … end L04, 2009-11-04ID1218, Christian Schulte 33

34. Scoping in Patterns Revisited  The following PID= …, receive {P,…} when P==PID -> … end can be rewritten to PID= …, receive {PID,…} -> … end  Variables already introduced are not pattern variables but the values they are assigned to whoa, this is ugly (my personal taste) L04, 2009-11-04ID1218, Christian Schulte 34

35. A Working RPC Client rpc(Server,Request) -> Server ! {self(),Request}, receive {Server,Response} -> Response end.  This is still easy… but correct… but why: there can only be one pending reply not so easy to see L04, 2009-11-04ID1218, Christian Schulte 35

36. The Registry  Register processes under names (atoms) for example: clock, logger, …  Operations register(Name,Pid ) unregister(Name) whereis(Name) returns PID or undefined registered() returns all registered names  Example register(a,PID), a ! M  As always: the registry is scary… L04, 2009-11-04ID1218, Christian Schulte 36

37. Summary & Outlook L04, 2009-11-04 37 ID1218, Christian Schulte

38. Summary: Concurrency  Processes communicate by message sending feature ordered mailbox execute selective receive statements messages buffered until removed by receive are scheduled fairly can use timeouts  Simple concurrency pattern client – server request – reply L04, 2009-11-04ID1218, Christian Schulte 38

39. Outlook: L05  How can concurrent computations synchronize with each other cooperate  What are the properties of programs with and without message sending and message receipt L04, 2009-11-04ID1218, Christian Schulte 39