Abstraction and Mo dularity Mechanisms for Concurrent Computing Gul Agha Svend Frlund Wo oYoung Kim Ra jendra Panwar Anna Patterson and Daniel Sturman Department of Computer Science W Springeld Avenue University of Illinois at UrbanaChampaign Urbana IL USA Email aghafrolundwooyoungrajuannapsturmancsuiucedu Intro duction The transition from sequential to parallel and distributed computing has b een widely ac cepted as a ma jor paradigm shift o ccurring in Computer Science It has b een observed that the sequential programming mo del is inadequate for parallel and distributed computing At a conceptual level one can compare the fundamental intuition b etween sequential and concurrent computing as follows The sequential programming mo del essentially denes a computation as a sequence of instructions which manipulate a global store The standard abstraction mechanism for sequential programs is pro cedures Pro cedures glue a sequence of instructions they allow genericity by parameterization and reuse by substitution While this provides a go o d building blo ck for much of sequential programming it is an unsatisfactory mo del for parallel and distributed computing b ecause it do es not provide a communication mo del and it is not a meaningful abstraction of co ordination b etween concurrent comp onents In a paral lel computation some actions overlap in time by implication these events must b e distributed in space Concurrency refers to the potential ly parallel execution of programs In a concurrent computation the execution of some parts of a program may b e sequential or it may b e parallel Since concurrent programs sp ecify a par tial order of actions it provides us with the exibility to interleave the execution of commands in a program or to run them in parallel Therefore some of the details of the order of execution are left unsp ecied We can instead concentrate on conceptual issues without necessarily b eing concerned with the particular order of execution that may b e the result of the quirks of a given system Part of the complexity of reasoning ab out concurrent programs results from the fact that partial orders allow considerable indeterminacy in execution In other words there are many p otential execution paths Furthermore concurrent programs are complicated by the fact that there are a numb er of dierent kinds of design concerns such as lo cality and synchronization that are transparent in sequential execution environments To simplify the construction of concurrent systems concurrent abstractions must supp ort a separation of design concerns by providing modularity The complexity of concurrent systems requires new abstraction metho ds to b e develop ed There are four imp ortant requirements for concurrency abstractions First the abstraction must allow sp ecication of the complex organizational and co ordination structures that are common in concurrent computing Second they must provide genericity and reuse of the co ordination patterns much as pro cedures do for sequential programming Third concur rency abstractions must simplify the task of programming by separating design concerns And nally the abstractions must allow ecient execution on concurrent architectures This pap er describ es a numb er of radical programming language concepts that supp ort abstraction and provide mo dularity in concurrent systems Sp ecically the constructs we prop ose allow abstract and mo dular sp ecication of co ordination patterns temp oral order ing resource management and dep endability proto cols In particular sp ecications using these constructs are generic and reusable The next four sections develop our metho dology and apply it to a numb er of problems as follows Actors we describ e the Actor mo del of concurrent computation The Actor mo del pro vides the basic building blo cks for concurrent programming which may b e used to build a wide variety of computational structures Communication abstractions three communication abstractions are discussed These are callreturn communication patterndirected message passing and constraints on reception To provide a concrete representation we show how callreturn communi cation is transformed to primitive actor messagepassing Ob ject oriented design we discuss the use of classes inheritance and incremental mo d ication of co de Mo dular decomp osition we describ e a set of abstractions and discuss how they may b e used to factor out multiactor co ordination patterns resource management strategies and proto cols for dep endability Actors The universe we live in is inherently parallel and distributed This suggests that the natural language constructs we use to describ e the world may also b e useful for mo deling compu tational systems It can b e reasonably asserted that the most imp ortant concept we use to mo del the world is categorizing it in terms of ob jects In fact the rst elements of natural language children learn are names of ob jects Computational ob jects encapsulate a state and an exp ected b ehavior Furthermore ob jects provide an interface dened in terms of the names of pro cedures that are visible These pro cedures called methods manipulate the lo cal state of the ob ject when invoked In particular this implies that representations which supp ort the same functionality may b e interchanged transparently This is an imp ortant software engineering advantage which has proved its utility in sequential ob jectbased programming Traditional ob jectoriented programming is limited by a mind set which views program ming as a sequence of actions In particular this mo de confounds the natural autonomy and concurrency of ob jects sequential ob jectoriented languages allow only one ob ject to b e active at a time An ob jects b ehavior is viewed as a sequence of actions and this se quence is blo cked by invoking a metho d in another ob ject This is a rather contrived view it is more natural to view ob jects as virtual computational agents which may compute concurrently The Actor mo del unies ob jects and concurrency The mo dels building blo cks can b e describ ed and justied in fairly intuitive terms Actors are autonomous and concurrently executing ob jects which execute asynchronously ie at their own rate Actors may send each other messages Since actors are conceptually distributed in space communication b etween them is asynchronous Asynchronous communication preserves the available p o tential for parallel activity an actor sending a message asynchronously need not blo ck until the recipient is ready to receive or pro cess a message If a mo del requires a sender to blo ck it reduces the concurrency which may b e available In resp onse to receiving a message an actor may take the following sorts of actions send asynchronously send a message to a sp ecied actor create create an actor with the sp ecied b ehavior b ecome sp ecify a new b ehavior lo cal state to b e used by the actor to resp ond to the next message it pro cesses The message send primitive is the asynchronous analog of pro cedure invo cation It is the basic communication primitive causing a message to b e put in an actors mailb ox mail queue To send a message the identity mail address of the target of a communi cation needs to b e sp ecied Finally note that although the arrival order of messages is nondeterministic every message sent to an actor is guaranteed to b e eventually delivered The become primitive gives actors a historysensitive b ehavior necessary for shared mu table data ob jects This is in contrast to a purely functional programming mo del The create primitive is to concurrent programming what pro cedure abstraction is to sequen tial programming Newly created actors are autonomous and have a unique mail address Furthermore create dynamically extends computational space it thus subsumes the func tionality of new in Pascal or malloc in C Actor primitives form a simple but p owerful set up on which to build a wide range of higherlevel abstractions and concurrent programming paradigms Communication Abstractions Although p ointtop oint asynchronous message sending is the most ecient form of com munication in a distributed system concurrent languages must provide a numb er of com munication abstractions to simplify the task of programming Programmers using parallel or distributed computing need to understand the advantages and limitations of dierent communication abstractions We describ e three basic communication abstractions namely callreturn communication patterndirected communication and constrained reception CallReturn Communication In callreturn communication an ob ject invokes a numb er of other ob jects and waits for them to return a value b efore continuing execution A standard mechanism for callreturn communication in concurrent programming is remote procedure cal l a pro cedure calls an other pro cedure at a remote no de and waits for the result The result is returned to the p oint where the call is made RPC extends the sequential pro cedure call mo del where pro cedure calls follow a stack discipline which can b e eciently implemented on sequential pro cessors In case of highlevel actor languages concurrent RPCstyle calls allow a simple expression of functional parallelism In actor languages whether two actors are on the same no de or on dierent no des is transparent to the application co de Blo cking a sender in a callreturn communication is generally not desirable if the actor invoked is on a dierent no de available concurrency may b e unnecessarily lost If the sender holds the pro cessor while