C. Varela1 Distributed systems abstractions (PDCS 9, CPE 6*) Carlos Varela Rennselaer Polytechnic Institute October 20, 2015 * Concurrent Programming in.

Slides:



Advertisements
Similar presentations
Categories of I/O Devices
Advertisements

COS 461 Fall 1997 Network Objects u first good implementation: DEC SRC Network Objects for Modula-3 u recent implementation: Java RMI (Remote Method Invocation)
More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
COMMUNICATING SEQUENTIAL PROCESSES C. A. R. Hoare The Queen’s University Belfast, North Ireland.
Remote Procedure Call (RPC)
Remote Procedure Call Design issues Implementation RPC programming
 2004 Deitel & Associates, Inc. All rights reserved. 1 Chapter 3 – Process Concepts Outline 3.1 Introduction 3.1.1Definition of Process 3.2Process States:
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Tam Vu Remote Procedure Call CISC 879 – Spring 03 Tam Vu March 06, 03.
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
C. Varela1 Actors (PDCS 4) AMST actor language syntax, semantics, join continuations Carlos Varela Rennselaer Polytechnic Institute April 16, 2015.
George Blank University Lecturer. CS 602 Java and the Web Object Oriented Software Development Using Java Chapter 4.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Erlang concurrency. Where were we? Finished talking about sequential Erlang Left with two questions  retry – not an issue; I mis-read the statement in.
Concurrency CS 510: Programming Languages David Walker.
Lecture 19 Distributed Programming (Ch. 10) Other message-passing programming models  Channels vs mailboxes  Synchronous vs asynchronous.
Inter Process Communication:  It is an essential aspect of process management. By allowing processes to communicate with each other: 1.We can synchronize.
ITERATIVE COMPUTATIONS CONCURRENCY ID1218 Lecture Christian Schulte Software and Computer Systems School of Information and.
Concurrency - 1 Tasking Concurrent Programming Declaration, creation, activation, termination Synchronization and communication Time and delays conditional.
Fundamentals of Python: From First Programs Through Data Structures
Comparative Programming Languages hussein suleman uct csc304s 2003.
SALSA: Language and Architecture for Widely Distributed Actor Systems. Carlos Varela, Abe Stephens, Department of.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 3: Processes. 3.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 7, 2006 Process Concept Process – a program.
111 © 2002, Cisco Systems, Inc. All rights reserved.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
IBM TSpaces Lab 1 Introduction. Summary TSpaces Overview Basic Definitions Basic primitive operations Reading/writing tuples in tuplespace HelloWorld.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
1 Concurrency Architecture Types Tasks Synchronization –Semaphores –Monitors –Message Passing Concurrency in Ada Java Threads.
OS2- Sem ; R. Jalili Introduction Chapter 1.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Threaded Programming in Python Adapted from Fundamentals of Python: From First Programs Through Data Structures CPE 401 / 601 Computer Network Systems.
C. Varela1 Mobility, garbage collection, load balancing, visualization (SALSA) Fault-tolerance, hot code loading (Erlang) (PDCS 9; CPE 7*) Carlos Varela.
Java Thread and Memory Model
C. Varela1 Actors in SALSA and Erlang (PDCS 9, CPE 5*) Support for actor model in SALSA and Erlang Carlos Varela Rennselaer Polytechnic Institute October.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Concurrency Properties. Correctness In sequential programs, rerunning a program with the same input will always give the same result, so it makes sense.
Hwajung Lee. Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity, non-determinism,
Chapter 2 Process Management. 2 Objectives After finish this chapter, you will understand: the concept of a process. the process life cycle. process states.
Thread A thread represents an independent module of an application that can be concurrently execution With other modules of the application. MULTITHREADING.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Implementing Remote Procedure Calls Andrew D. Birrell and Bruce Jay Nelson Xerox Palo Alto Research Center Published: ACM Transactions on Computer Systems,
Concurrent Object-Oriented Programming Languages Chris Tomlinson Mark Scheevel.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Erlang Erricsson and Ellemtel Computer Science Laboratories
1 Lecture 19: Unix signals and Terminal management n what is a signal n signal handling u kernel u user n signal generation n signal example usage n terminal.
Concurrency in Java MD. ANISUR RAHMAN. slide 2 Concurrency  Multiprogramming  Single processor runs several programs at the same time  Each program.
Distributed Computing & Embedded Systems Chapter 4: Remote Method Invocation Dr. Umair Ali Khan.
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
WORKING OF SCHEDULER IN OS
Advanced Operating Systems CIS 720
Carlos Varela Rennselaer Polytechnic Institute November 1, 2016
Definition of Distributed System
Distributed systems abstractions (PDCS 9, CPE 6*)
Chapter 2 Processes and Threads Today 2.1 Processes 2.2 Threads
Chapter 3 – Process Concepts
Rennselaer Polytechnic Institute
Carlos Varela Rennselaer Polytechnic Institute November 3, 2017
Advanced Operating Systems
Carlos Varela Rennselaer Polytechnic Institute October 6, 2017
Concurrency: Mutual Exclusion and Synchronization
Distributed (Systems) Programming Universal Actors, SALSA, World-Wide Computer Carlos Varela RPI C. Varela.
Object Oriented Programming
Concurrency control abstractions (PDCS 9, CPE 5*)
Carlos Varela Rennselaer Polytechnic Institute October 4, 2016
Computer Science 312 Concurrent Programming I Processes and Messages 1.
Concurrent Programming Actors, SALSA, Coordination Abstractions
Presentation transcript:

C. Varela1 Distributed systems abstractions (PDCS 9, CPE 6*) Carlos Varela Rennselaer Polytechnic Institute October 20, 2015 * Concurrent Programming in Erlang, by J. Armstrong, R. Virding, C. Wikström, M. Williams

C. Varela2 Actor Languages Summary Actors are concurrent entities that react to messages. –State is completely encapsulated. There is no shared memory! –Message passing is asynchronous. –Actors can create new actors. Run-time has to ensure fairness. AMST extends the call by value lambda calculus with actor primitives. State is modeled as function arguments. Actors use ready to receive new messages. SALSA extends an object-oriented programming language (Java) with universal actors. State is explicit, encapsulated in instance variables. Control loop is implicit: ending a message handler, signals readiness to receive a new message. Actors are garbage-collected. Erlang extends a functional programming language core with processes that run arbitrary functions. State is implicit in the function’s arguments. Control loop is explicit: actors use receive to get a message, and tail-form recursive call to continue. Ending a function denotes process (actor) termination.

Tree Product Behavior in AMST B treeprod = rec(λb.λm. seq(if(isnat(tree(m)), send(cust(m),tree(m)), let newcust=new(B joincont (cust(m))), lp = new(B treeprod ), rp = new(B treeprod ) in seq(send(lp, pr(left(tree(m)),newcust)), send(rp, pr(right(tree(m)),newcust)))), ready(b))) C. Varela3

Join Continuation in AMST B joincont = λcust.λfirstnum.ready(λnum. seq(send(cust,firstnum*num), ready(sink))) C. Varela4

5 Tree Product Behavior in SALSA module treeprod; behavior TreeProduct { void compute(Tree t, UniversalActor c){ if (t.isLeaf()) c <- result(t.value()); else { JoinCont newCust = new JoinCont(c); TreeProduct lp = new TreeProduct(); TreeProduct rp = new TreeProduct(); lp <- compute(t.left(), newCust); rp <- compute(t.right(), newCust); }

C. Varela6 Join Continuation in SALSA module treeprod; behavior JoinCont { UniversalActor cust; int first; boolean receivedFirst; JoinCont(UniversalActor cust){ this.cust = cust; this.receivedFirst = false; } void result(int v) { if (!receivedFirst){ first = v; receivedFirst = true; } else // receiving second value cust <- result(first*v); }

Tree Product Behavior in Erlang -module(treeprod). -export([treeprod/0,join/1]). treeprod() -> receive {{Left, Right}, Customer} -> NewCust = spawn(treeprod,join,[Customer]), LP = spawn(treeprod,treeprod,[]), RP = spawn(treeprod,treeprod,[]), LP!{Left,NewCust}, RP!{Right,NewCust}; {Number, Customer} -> Customer ! Number end, treeprod(). join(Customer) -> receive V1 -> receive V2 -> Customer ! V1*V2 end end. C. Varela7

8 Concurrency Control in SALSA SALSA provides three main coordination constructs: –Token-passing continuations To synchronize concurrent activities To notify completion of message processing Named tokens enable arbitrary synchronization (data-flow) –Join blocks Used for barrier synchronization for multiple concurrent activities To obtain results from otherwise independent concurrent processes –First-class continuations To delegate producing a result to a third-party actor

C. Varela9 Token Passing syntax using token as an argument is syntactic sugar. –Example 1: a1 <- a2 <- m2( token ); is syntactic sugar for: token t = a1 <- m1(); a2 <- m2( t ); –Example 2: a1 <- a2 <- m2(); is syntactic sugar for: token t = a1 <- m1(); a2 <- m2():waitfor( t );

C. Varela10 Named Tokens Tokens can be named to enable more loosely- coupled synchronization –Example: token t1 = a1 <- m1(); token t2 = a2 <- m2(); token t3 = a3 <- m3( t1 ); token t4 = a4 <- m4( t2 ); a <- m(t1,t2,t3,t4); Sending m(…) to a will be delayed until messages m1()..m4() have been processed. m1() can proceed concurrently with m2().

C. Varela11 Join Blocks Provide a mechanism for synchronizing the processing of a set of messages. Set of results is sent along as a token containing an array of results. –Example: UniversalActor[] actors = { searcher0, searcher1, searcher2, searcher3 }; join { for (int i=0; i < actors.length; i++){ actors[i] <- find( phrase ); } resultActor <- output( token ); Send the find( phrase ) message to each actor in actors[] then after all have completed send the result to resultActor as the argument of an output( … ) message.

C. Varela12 First Class Continuations Enable actors to delegate computation to a third party independently of the processing context. For example: int m(…){ b <- currentContinuation; } Ask (delegate) actor b to respond to this message m on behalf of current actor ( self ) by processing b ’s message n.

C. Varela13 Tree Product Behavior Revisited module treeprod; behavior JoinTreeProduct { int multiply(Object[] results){ return (Integer) results[0] * (Integer) results[1]; } int compute(Tree t){ if (t.isLeaf()) return t.value(); else { JoinTreeProduct lp = new JoinTreeProduct(); JoinTreeProduct rp = new JoinTreeProduct(); join { lp <- compute(t.left()); rp <- compute(t.right()); currentContinuation; } Notice we use token-passing continuations token ), a join block ( join ), and a first- class continuation ( currentContinuation ).

C. Varela14 Concurrency control in Erlang Erlang uses a selective receive mechanism to help coordinate concurrent activities: –Message patterns and guards To select the next message (from possibly many) to execute. To receive messages from a specific process (actor). To receive messages of a specific kind (pattern). –Timeouts To enable default activities to fire in the absence of messages (following certain patterns). To create timers. –Zero timeouts ( after 0 ) To implement priority messages, to flush a mailbox.

Selective Receive receive MessagePattern1 [when Guard1] -> Actions1 ; MessagePattern2 [when Guard2] -> Actions2 ; … end receive suspends until a message in the actor’s mailbox matches any of the patterns including optional guards. Patterns are tried in order. On a match, the message is removed from the mailbox and the corresponding pattern’s actions are executed. When a message does not match any of the patterns, it is left in the mailbox for future receive actions. C. Varela15

Selective Receive Example Example program and mailbox (head at top): receive msg_b -> … end receive tries to match msg_a and fails. msg_b can be matched, so it is processed. Suppose execution continues: receive msg_c -> … msg_a -> … end The next message to be processed is msg_a since it is the next in the mailbox and it matches the 2 nd pattern. C. Varela16 msg_a msg_b msg_c msg_a msg_c

Receiving from a specific actor Actor ! {self(), message} self() is a Built-In-Function (BIF) that returns the current (executing) process id (actor name). Ids can be part of a message. receive {ActorName, Msg} when ActorName == A1 -> … end receive can then select only messages that come from a specific actor, in this example, A1. (Or other actors that know A1’s actor name.) C. Varela17

Receiving a specific kind of message counter(Val) -> receive increment -> counter(Val+1); {From,value} -> From ! {self(), Val}, counter(Val); stop -> true; Other -> counter(Val) end. counter is a behavior that can receive increment messages, value request messages, and stop messages. Other message kinds are ignored. C. Varela18 increment is an atom whereas Other is a variable (that matches anything!).

Order of message patterns matters receive {{Left, Right}, Customer} -> NewCust = spawn(treeprod,join,[Customer]), LP = spawn(treeprod,treeprod,[]), RP = spawn(treeprod,treeprod,[]), LP!{Left,NewCust}, RP!{Right,NewCust}; {Number, Customer} -> Customer ! Number end In this example, a binary tree is represented as a tuple {Left, Right}, or as a Number, e.g., {{{5,6},2},{3,4}} C. Varela19 {Left,Right} is a more specific pattern than Number is (which matches anything!). Order of patterns is important.

Selective Receive with Timeout receive MessagePattern1 [when Guard1] -> Actions1 ; MessagePattern2 [when Guard2] -> Actions2 ; … after TimeOutExpr -> ActionsT end TimeOutExpr evaluates to an integer interpreted as milliseconds. If no message has been selected within this time, the timeout occurs and ActionsT are scheduled for evaluation. A timeout of infinity means to wait indefinitely. C. Varela20

Timer Example sleep(Time) -> receive after Time -> true end. sleep(Time) suspends the current actor for Time milliseconds. C. Varela21

Timeout Example receive click -> receive click -> double_click after double_click_interval() -> single_click end... end double_click_interval evaluates to the number of milliseconds expected between two consecutive mouse clicks, for the receive to return a double_click. Otherwise, a single_click is returned. C. Varela22

Zero Timeout receive MessagePattern1 [when Guard1] -> Actions1 ; MessagePattern2 [when Guard2] -> Actions2 ; … after 0 -> ActionsT end A timeout of 0 means that the timeout will occur immediately, but Erlang tries all messages currently in the mailbox first. C. Varela23

Zero Timeout Example flush_buffer() -> receive AnyMessage -> flush_buffer() after 0 -> true end. flush_buffer() completely empties the mailbox of the current actor. C. Varela24

Priority Messages priority_receive() -> receive interrupt -> interrupt after 0 -> receive AnyMessage -> AnyMessage end end. priority_receive() will return the first message in the actor’s mailbox, except if there is an interrupt message, in which case, interrupt will be given priority. C. Varela25

C. Varela26 Overview of programming distributed systems It is harder than concurrent programming! Yet unavoidable in today’s information-oriented society, e.g.: –Internet, mobile devices –Web services –Cloud computing Communicating processes with independent address spaces Limited network performance –Orders of magnitude difference between WAN, LAN, and intra-machine communication. Localized heterogeneous resources, e.g, I/O, specialized devices. Partial failures, e.g. hardware failures, network disconnection Openness: creates security, naming, composability issues.

C. Varela27 SALSA Revisited SALSA –Simple Actor Language System and Architecture –An actor-oriented language for mobile and internet computing –Programming abstractions for internet-based concurrency, distribution, mobility, and coordination C. Varela and G. Agha, “Programming dynamically reconfigurable open systems with SALSA”, ACM SIGPLAN Notices, OOPSLA 2001 Intriguing Technology Track, 36(12), pp Advantages for distributed computing –Actors encapsulate state and concurrency: Actors can run in different machines. Actors can change location dynamically. –Communication is asynchronous: Fits real world distributed systems. –Actors can fail independently.

C. Varela28 World-Wide Computer (WWC) Distributed computing platform. Provides a run-time system for universal actors. Includes naming service implementations. Remote message sending protocol. Support for universal actor migration.

C. Varela29 Abstractions for Worldwide Computing Universal Actors, a new abstraction provided to guarantee unique actor names across the Internet. Theaters, extended Java virtual machines to provide execution environment and network services to universal actors: –Access to local resources. –Remote message sending. –Migration. Naming service, to register and locate universal actors, transparently updated upon universal actor creation, migration, garbage collection.

C. Varela30 Universal Actor Names (UAN) Consists of human readable names. Provides location transparency to actors. Name to locator mapping updated as actors migrate. UAN servers provide mapping between names and locators. –Example Universal Actor Name: uan://wwc.cs.rpi.edu:3030/cvarela/calendar Name server address and (optional) port. Unique relative actor name.

C. Varela31 WWC Theaters Theater address and port. Actor location.

C. Varela32 Universal Actor Locators (UAL) Theaters provide an execution environment for universal actors. Provide a layer beneath actors for message passing and migration. When an actor migrates, its UAN remains the same, while its UAL changes to refer to the new theater. Example Universal Actor Locator: rmsp://wwc.cs.rpi.edu:4040 Theater’s IP address and (optional) port.

C. Varela33 SALSA Language Support for Worldwide Computing SALSA provides linguistic abstractions for: –Universal naming (UAN & UAL). –Remote actor creation. –Location-transparent message sending. –Migration. –Coordination. SALSA-compiled code closely tied to WWC run-time platform.

C. Varela34 Universal Actor Creation To create an actor locally TravelAgent a = new TravelAgent(); To create an actor with a specified UAN and UAL: TravelAgent a = new TravelAgent() at (uan, ual); To create an actor with a specified UAN at current location: TravelAgent a = new TravelAgent() at (uan);

C. Varela35 Message Sending TravelAgent a = new TravelAgent(); a <- book( flight ); Message sending syntax is the same ( <- ), independently of actor’s location.

C. Varela36 Remote Message Sending Obtain a remote actor reference by name. TravelAgent a = (TravelAgent) TravelAgent.getReferenceByName(“uan://myhost/ta”); a <- printItinerary();

C. Varela37 Reference Cell Service Example module dcell; behavior Cell implements ActorService{ Object content; Cell(Object initialContent) { content = initialContent; } Object get() { standardOutput <- println (“Returning: ”+content); return content; } void set(Object newContent) { standardOutput <- println (“Setting: ”+newContent); content = newContent; } implements ActorService signals that actors with this behavior are not to be garbage collected.

C. Varela38 Reference Cell Tester module dcell; behavior CellTester { void act( String[] args ) { if (args.length != 2){ standardError <- println( “Usage: salsa dcell.CellTester ”); return; } Cell c = new Cell(0) at (new UAN(args[0]), new UAL(args[1])); standardOutput <- print( “Initial Value:” c <- standardOutput <- println( token ); }

C. Varela39 Reference Cell Client Example module dcell; behavior GetCellValue { void act( String[] args ) { if (args.length != 1){ standardOutput <- println( “Usage: salsa dcell.GetCellValue ”); return; } Cell c = (Cell) Cell.getReferenceByName(args[0]); standardOutput <- print(“Cell c <- standardOutput <- println(token); }

C. Varela40 Address Book Service module addressbook; import java.util.* behavior AddressBook implements ActorService { Hashtable name2 ; AddressBook() { name2 = new HashTable(); } String getName(String ) { … } String get (String name) { … } boolean addUser(String name, String ) { … } void act( String[] args ) { if (args.length != 0){ standardOutput -Dual= addressbook.AddressBook”); }

C. Varela41 Address Book Add User Example module addressbook; behavior AddUser { void act( String[] args ) { if (args.length != 3){ standardOutput<-println(“Usage: salsa addressbook.AddUser ”); return; } AddressBook book = (AddressBook) AddressBook.getReferenceByName(new UAN(args[0])); book<-addUser(args(1), args(2)); }

C. Varela42 Address Book Get Example module addressbook; behavior Get { void act( String[] args ) { if (args.length != 2){ standardOutput <- println(“Usage: salsa addressbook.Get ”); return; } get (args(0),args(1)); } void get (String uan, String name){ try{ AddressBook book = (AddressBook) AddressBook.getReferenceByName(new UAN(uan)); standardOutput <- print(name + “’s book <- standardOutput <- println(token); } catch(MalformedUANException e){ standardError<-println(e); }

C. Varela43 Erlang Language Support for Distributed Computing Erlang provides linguistic abstractions for: –Registered processes (actors). –Remote process (actor) creation. –Remote message sending. –Process (actor) groups. –Error detection. Erlang-compiled code closely tied to Erlang node run-time platform.

C. Varela44 Erlang Nodes To return our own node name: node() To return a list of other known node names: nodes() To monitor a node: monitor_node(Node, Flag) If flag is true, monitoring starts. If false, monitoring stops. When a monitored node fails, {nodedown, Node} is sent to monitoring process.

C. Varela45 Actor Creation To create an actor locally Agent = spawn(travel, agent, []); To create an actor in a specified remote node: Agent = spawn(host, travel, agent, []); travel is the module name, agent is the function name, Agent is the actor name. host is the node name.

C. Varela46 Actor Registration To register an actor: register(ta, Agent) To return the actor identified with a registered name: whereis(ta) To remove the association between an atom and an actor: unregister(ta) ta is the registered name (an atom), Agent is the actor name (PID).

C. Varela47 Message Sending Agent = spawn(travel, agent, []), register(ta, Agent) Agent ! {book, Flight} ta ! {book, Flight} Message sending syntax is the same ( ! ) with actor name ( Agent ) or registered name ( ta ).

C. Varela48 Remote Message Sending To send a message to a remote registered actor: {ta, host} ! {book, Flight}

C. Varela49 Reference Cell Service Example -module(dcell). -export([cell/1,start/1]). cell(Content) -> receive {set, NewContent} -> cell(NewContent); {get, Customer} -> Customer ! Content, cell(Content) end. start(Content) -> register(dcell, spawn(dcell, cell, [Content]))

C. Varela50 Reference Cell Tester -module(dcellTester). -export([main/0]). main() -> dcell:start(0), dcell!{get, self()}, receive Value -> io:format(”Initial Value:~w~n”,[Value]) end.

C. Varela51 Reference Cell Client Example -module(dcellClient). -export([getCellValue/1]). getCellValue(Node) -> {dcell, Node}!{get, self()}, receive Value -> io:format(”Initial Value:~w~n”,[Value]) end.

C. Varela52 Address Book Service -module(addressbook). -export([start/0,addressbook/1]). start() -> register(addressbook, spawn(addressbook, addressbook, [[]])). addressbook(Data) -> receive {From, {addUser, Name, }} -> From ! {addressbook, ok}, addressbook(add(Name, , Data)); {From, {getName, }} -> From ! {addressbook, getname( , Data)}, addressbook(Data); {From, {get , Name}} -> From ! {addressbook, get (Name, Data)}, addressbook(Data) end. add(Name, , Data) -> … getname( , Data) -> … get (Name, Data) -> …

C. Varela53 Address Book Client Example -module(addressbook_client). -export([get /1,getName/1,addUser/2]). addressbook_server() -> get (Name) -> call_addressbook({get , Name}). getName( ) -> call_addressbook({getName, }). addUser(Name, ) -> call_addressbook({addUser, Name, }). call_addressbook(Msg) -> AddressBookServer = addressbook_server(), monitor_node(AddressBookServer, true), {addressbook, AddressBookServer} ! {self(), Msg}, receive {addressbook, Reply} -> monitor_node(AddressBookServer, false), Reply; {nodedown, AddressBookServer} -> no end.

C. Varela54 Exercises 51.How would you implement the join continuation linguistic abstraction considering different potential distributions of its participating actors? 52.CTM Exercise (page 746). Implement the example using SALSA/WWC and Erlang. 53.PDCS Exercise (page 203). 54.PDCS Exercise (page 204). 55.PDCS Exercise (page 204). 56.Write the same distributed programs in Erlang.