ParaDOS: A Parameterized, Para llel and

D istributed Operational Semantics |

Toward a Parameterized Model for Reasoning about

Parallel and Distributed Computation 1

Marc L. Smith2

School of Computer Science

University of Central Florida

Orlando, FL 32816-2362

October 2, 1998

Revised February 1, 2000

Research Committee:

Rebecca J. Parsons, co-Chair

Charles E. Hughes, co-Chair

Mostafa A. Bassiouni

Ronald F. DeMara

1UCF School of Computer Science Technical Report No. CS-TR-99-052In partial ful�llment of requirements for candidacy examination.

Abstract

This paper proposes a new computational model for parallel and distributed systems (PDSs).

Traditional sequential models of computation (e.g. Turing machines) do not possess the level

of abstraction needed for reasoning about critical aspects of parallel and distributed com-

putation. Augmenting a sequential system with additional processors introduces signi�cant

complexities associated with managing multiple concurrent activities; this is just the parallel

aspect of PDSs. Parallel processors that are also distributed across multiple remote loca-

tions introduce further complexities associated with the physical limitations of long distance

communication. A computational model for PDSs must at once abstract away cumbersome

details while providing a mechanism that promotes reasoning about important aspects of such

systems. As a �rst step toward achieving such a model, this paper presents an operational

semantics for actors, a widely employed paradigm for PDS computation.

Contents

1 Scope and Motivation 4

2 Related Work 6

2.1 Existing PDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Other PDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Classic Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Operational Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 An Operational Semantics for Actors 12

3.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 De�nitions and Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Proposed Future Work 20

4.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Taxonomy of PDS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 The Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Characterizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Bibliography 29

A Function De�nitions 30

A.1 Function Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.2 Pact Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.3 Pact Helper Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A.4 dPact Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

B Equivalence Proof 34

B.1 Proof Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

B.1.1 AT Predicates and Helper Functions . . . . . . . . . . . . . . . . . . . 34

1

B.1.2 Pact Predicates and Helper Functions . . . . . . . . . . . . . . . . . . . 34

B.1.3 Equivalence Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B.2 Theorem and Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

C Scheme Implementation of SECD Machine 55

2

List of Tables

4.1 Table of Features versus PDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3

Chapter 1

Scope and Motivation

This paper proposes a new computational model for parallel and distributed systems (PDSs).

Traditional sequential models of computation (e.g. Turing machines) do not possess the level

of abstraction needed for reasoning about critical aspects of parallel and distributed com-

putation. Augmenting a sequential system with additional processors introduces signi�cant

complexities associated with managing multiple concurrent activities; this is just the parallel

aspect of PDSs. Parallel processors that are also distributed across multiple remote loca-

tions introduce further complexities associated with the physical limitations of long distance

communication. A computational model for PDSs must at once abstract away cumbersome

details while providing a mechanism that promotes reasoning about important aspects of

such systems.

One way to characterize the di�erence between sequential and PDS computation is to

discuss computation in terms of events, traces, and views. A trace describes the history

of a system's computation. The trace of a sequential system is comprised of a sequence

of observable events that occur during computation. Reasoning about a system's trace is

equivalent to reasoning about its computation. Computational traces for PDSs di�er from

those of sequential systems in two important ways:

1. Due to the parallel nature of PDS computation, these traces are comprised of parallel

events rather than singular events, and

2. Due to the distributed nature of PDS computation and the existence of multiple simul-

taneous observers, multiple distinct views corresponding to these observers are possible.

One particularly expressive description of PDS traces, and the central focus of the on-

going research presented in this paper, is a model of computation that employs operational

semantics [27]. An operational semantics for a PDS must be capable of modeling any possible

instance of a computation, as well as providing a mechanism for distinguishing between a

given computation of the system and the multiple views of that computation. Important

elements of an operational semantics include:

1. the PDS's computation space, or states;

4

2. the state transition function;

3. the state transition history (actual computation); and

4. the multiple views of actual computation.

We de�ned an operational semantics for actors [4] that possesses the above four impor-

tant elements; this work is presented in Chapter 3. Actors is a PDS for research in the

academic community, while other PDSs, including Java, the Object Management Group's

Common Object Request Broker Architecture (CORBA), and the Department of Defense's

High Level Architecture (HLA), are the focuses of industry and government research. Each

of these three PDSs has its own unique design priorities, but all have much in common with

each other. A well-de�ned, parameterized, parallel and distributed operational semantics

(ParaDOS) for these PDSs is therefore desirable. Such a computational model would enable

both understanding and reasoning about PDSs.

Reasoning about PDSs (or their traces) refers to considering classic computer science

problems, such as deadlocks, in�nite postponement, synchronization mechanisms, view con-

sistency, etc. An important goal for a formal model of PDS computation, is the support for

reasoning about properties that are:

1. inherent in PDS computation, or

2. peculiar to only certain PDS computations.

The goal of our work is to develop such a system. An operational semantics for actors is a

�rst step toward reasoning more generally about parallel and distributed computation.

The remainder of this paper is devoted to presenting our work on the development of

ParaDOS, a parameterized operational semantics for reasoning about parallel and distributed

systems.

5

Chapter 2

Related Work

Related work concerning PDSs is either from the perspective of a PDS or from that of a

classic PDS problem. This chapter presents relavent work from both of these perspectives.

Also related to our research is work in the area of operational semantics, since this is the basis

for the computational model being developed. Section 2.1 presents existing PDSs, section 2.2

introduces material on classic PDS problems, and section 2.3 discusses the area of operational

semantics.

2.1 Existing PDSs

This section gives an overview of important PDSs in the literature that are being considered

for modeling by ParaDOS. Section 2.1.1 goes into more detail about actors since this is the

PDS that has been studied the most in our research to date. Section 2.1.2 discusses other

important PDSs we have chosen to be modeled by ParaDOS.

2.1.1 Actors

The operational semantics for actors presented in Chapter 3 is based on the actors model

of concurrent computation in distributed systems described by Agha [4]. At the core of

this model is the concept of computational agents (actors). The remainder of this section

discusses actors and actor computation in su�cient detail to enable the reader to understand

the semantics presented in the next chapter.

Actors compute in response to messages they receive. For each message an actor receives,

it can (based on its behavior at the time it receives this message) send messages to other

actors, create new actors, and specify its own replacement behavior (not necessarily in this

or any other order). There is still much to say about implementation assumptions and the

implications of these requirements (in terms of what is and is not speci�ed). Let's consider

each of these requirements in turn, and discuss brie y some of the implications.

An actor can send messages to other actors. This is the only way one actor can a�ect

6

the behavior of another. While there is a guarantee of delivery for all sent messages, there

is no guarantee that the order of receipt will be the same as that of transmission, or even

that the order of receipt will be the same for all recipients. Thus, the promise of delivery

is the total extent of fairness required. Furthermore, actors communicate asynchronously

since synchronous communication would limit parallelism and, in a distributed system, be

problematic to implement. Asynchronous messages also increase the level of non-determinism

in the actor model, an important consequence of PDSs.

An actor can create new actors. Any sequence of independent expressions that can be

computed in parallel can take advantage of new actors to do so. Sub-expression results can

be communicated back to other actors waiting for that result. Compilers can perform sub-

expression analysis to maximize parallelism, based on hardware and run-time constraints, so

as not to burden the programmer. Thus, the actors model does not unnecessarily constrain

otherwise inherent parallelism, or distributivity.

An actor can specify its own replacement behavior. This replacement behavior will govern

what that actor does with the next message it receives. In this way, actors can be history

sensitive. An actor's actions are a function of its behavior at the time a message is received

and the content of the message. One of an actor's actions is to specify its replacement

behavior for the next message.

This concludes the overview of actors. Actors is a seductive PDS in that it embodies three

simple requirements, yet contains all the power and complexity inherent in PDS computation.

Given the proliferation of requirements and speci�cations for other PDSs which possess no

greater parallel and distributed processing capabilities than actors, the actor model is the

logical choice to begin development of ParaDOS. Section 2.1.2 presents other PDSs we will

be studying in our research.

2.1.2 Other PDSs

David Gelernter's Linda model [16] has left an indelible mark on several PDSs, including

actors, the Java family of PDSs, and IBM's T Spaces [31]. The tuple space of Linda has

been reincarnated into both ActorSpace and JavaSpace of actors and Jini, respectively. IBM

introduced their own T Spaces implementation of tuplespace, written in Java. These spaces

are all similar but distinct from each other. Their di�erences should provide valuable insights

into our future work.

The ActorSpace model was introduced by [7, 2, 1] as an extension to the work on actors

by [4]. Since Linda's tuplespace has also had a profound e�ect on the development of the

Java PDSs, we have chosen to study Linda to the extent that it helps us understand the

relationship between the ActorSpace and JavaSpace variations of tuplespace. Implementing

both ActorSpace and Javaspace instantiations of ParaDOS should provide a valuable point

of comparison.

Our interest in the Java-related PDSs derives from these systems' internet-related design

goals. Java's symbiotic relationship with web browsers has made its presence in internet-based

applications ubiquitous. The emerging Java standards are still immature and currently in a

7

state of ux. The Java RMI and Javaspace packages each provide the capabilities of a PDS;

the Jini package includes both the RMI and Javaspace packages as important parts of the

PDS it de�nes. Since the Java family of PDSs cannot be ignored in industry today, care

must be taken when studying these PDSs to distinguish between the facts about the systems

and the media hype. Ultimately, ParaDOS will be a model to help others do the same. Java

and its PDSs are so young that not much formal theoretical work has been published in this

area; exceptions include [25, 20].

While the Java-based PDSs are designed to support cross-platform applications, they

are limited to applications written entirely in Java. This is where our interest in CORBA

picks up. The CORBA standard was designed prior to the explosion of popularity in the

internet due to the world wide web, but it was designed with the goal of heterogeneous

computing in mind. In other words, CORBA is not only a cross-platform PDS, but also a

cross-language PDS. CORBA was designed by the Object Management Group (OMG), an

industry consortium of corporations and organizations with a common interest in distributed

object computing. The OMG's CORBA speci�cation is a juggernaut, and the extent to

which ParaDOS assimilates CORBA is discussed in section 4.2.

The Department of Defense (DoD) is one of the submitting members of CORBA's OMG

consortium. Recently, the DoD has submitted their High Level Architecture (HLA) for

adoption in the CORBA 3.0 speci�cation. The DoD's HLA has the backing of the government

for all simulation work. In a sense, the HLA standard is not unlike that of CORBA in that

it is a continuing, evolving speci�cation. Not surprisingly, HLA is a juggernaut in its own

right. We are primarily concerned with the runtime infrastructure (RTI) component of HLA,

and its real-time simulation capabilities. Of particular interest from a modeling standpoint is

RTI's native publish-subscribe metaphor, both from a messaging standpoint and concerning

transactions. Beyond implementing the publish-subscribe metaphor in ParaDOS, the extent

to which ParaDOS further assimilates HLA's RTI is still to be determined.

2.2 Classic Problems

The problems encountered in parallel and distributed systems are not new. Not surprisingly,

these are the same problems that must be addressed by multi-user operating systems (OSs)

and database management systems (DBMSs). This is true because OSs and DBMSs are but

instances of PDSs. Therefore, references to PDS computation in this section will apply not

only to PDSs, but to PDS instances.

The classic problems of PDS computation concern communication and coordination. The

literature discusses these problems on several levels of abstraction. The �rst level is the

communication level. There are two standard mechanisms for interprocess communication,

shared memory and message passing. Furthermore, two varieties of message passing exist,

synchronous and asynchronous.

The next level of abstraction is coordination, also called synchronization. Message pass-

ing simultaneously exists at the communication and coordination levels of abstraction. In

8

contrast, shared memory requires an additional mechanism to handle synchronization, since

memory contention can exist. Coordination solutions to overcome memory contention also

extend to shared resource allocation, and include (in addition to message passing) semaphores

and monitors. The coordination level provides schemes to specify critical sections of code,

that is blocks of code that may be executed by only one process at a time.

Notice that the problems of communication and coordination exist in parallel systems

that are not distributed. The added complexity of distributing a parallel system's proces-

sors across multiple distinct locations all but precludes the use of shared memory solutions.

Consequently, message passing is of great important in distributed (networked) systems, and

brings with it additional problems (e.g. network reliability).

The third level of abstraction discusses problems which can arise in PDSs despite { or

rather, as a consequence of { the mechanisms and approaches at the communication and

coordination levels. One problem is deadlock, which is a situation where two or more processes

are unable to proceed because each is waiting for one of the others to do something [19]. One

of the classic examples of this problem is the dining philosophers problem [11]. Since this

problem is well-known, it will not be described again in this paper.

Along with the problem of deadlock, comes the problem of deadlock detection, and re-

covery. The problem of starvation is also illustrated by the dining philosophers problem: is

it possible to ensure that all philosophers get to eat? Of course, by ensuring no starvation,

we don't wish to limit nondeterminism! Finally, the problem of divergence exists in the PDS

setting. Is it possible for one process to get in an in�nite loop, in the process preventing it

from communicating with other processes, and through a domino e�ect, cause a PDS-wide

deadlock?

An important test of ParaDOS will be if it can model solutions to the problems presented

in this section, for each of its instantiations.

2.3 Operational Semantics

This section provides a brief introduction to operational semantics, a �eld that encompasses

any formal method used to describe the meaning of a program through the changes its

execution makes to the state of some computational model [27]. The following de�nition is

from [19]:

De�nition 1 (operational semantics) A set of rules specifying how the state of an actual

or hypothetical computer changes while executing a program. The overall state is typically

divided into a number of components, e.g. stacks, heaps, registers, etc. Each rule speci�es

certain preconditions on the contents of some components and their new contents after the

application of the rule.

An operational semantics can take many forms, specifying a formal or informal model of

computation, and is de�ned at a level of abstraction appropriate for the model's purpose.

9

Important references for work in operational semantics are [22, 24, 21, 23, 17]. The remainder

of this section introduces two examples of operational semantics as presented in [27].

The �rst example is a classic example of operational semantics, the SECD machine by

Peter Landin [22]. The purpose of the SECD machine is to evaluate lambda expressions. As

a result, the computational techniques employed by the SECD machine have been used in

implementations of functional programming languages. SECD's name comes from the names

of the four stacks which comprise its con�guration, or state.

S for Stack A structure for storing partial results awaiting subsequent use.

E for Environment A collection of bindings of values (actual parameters) to variables (for-

mal parameters).

C for Control A stack of lambda expressions yet to be evaluated plus a special symbol \@"

meaning that an application can be performed; the top expression on the stack is the

next one to be evaluated.

D for Dump A stack of complete states corresponding to evaluations in progress but sus-

pended while other expressions (inner redexes) are evaluated.

The notation for a state, then, is cfg(S;E; C;D). Finally, SECD has a transition function

that maps current con�gurations to next con�gurations. Formally, we specify this transition

function by the mapping transform : State! State. The SECD machine starts in an initial

state with the C stack containing the lambda expression to be evaluated, and the S, E, and

D stacks empty. A �nal state (if one exists for a given lambda expression) is recognized by

empty C and D stacks; the result is on top of the S stack. Implementing the SECD machine in

Scheme was an important personal milestone in my understanding of operational semantics.

My implementation is in Appendix C.

The SECD machine demonstrates one form of operational semantics, whose purpose

is the speci�cation of an abstract machine capable of carrying out the mechanical evalu-

ation of lambda expressions. Another form of operational semantics, developed by Gordon

Plotkin [24], is called structural operational semantics. Structural operational semantics

presents state transitions in the form of inference rules. Thus, the abstract machine becomes

a system of inference rules. The classic representation of an inference rule has premises listed

above a horizontal line, a conclusion below the line, and any required condition (if necessary),

to the right. Formally, here is the general form of an inference rule:

premise1 : : : premisen

conclusioncondition:

Inference rules can be used to specify the abstract syntax of a language, as well as the

semantics of expressions and commands. This latter use of inference rules, that is, for a

10

program, performing syntactic transformations of language elements to normal form val-

ues, constitutes program meaning. The formal technique of structural induction provides a

powerful mechanism for proving properties about programs.

We are employing operational semantics to develop a general computational model for

parallel and distributed computation. By general we mean a parameterized model capable of

instantiation into multiple parallel and distributed systems. Thus, our goal is a model that

goes beyond describing the meanings of programs for a particular programming language;

we intend ParaDOS to be generally applicable to a broad scope of compuational systems

and paradigms. The success of our research will provide further evidence of the utility of

operational semantics as an e�ective means to develop elegant models of computation that

support reasoning about the modelled systems.

11

Chapter 3

An Operational Semantics for Actors

De�ning an operational semantics for a PDS such as actors requires de�ning the elements

discussed in this paper's introduction: the computation space (states), the state transition

function, the state transition history (actual computation), and the multiple views of actual

computation. Taken together, these elements describe how computation in a PDS proceeds,

and they provide an expressive framework that promotes reasoning about parallel and dis-

tributed computation. This chapter presents a conceptual discussion of the model, followed

by the data structures and functions required to implement an operational semantics for

actors.

3.1 Concepts

The computation space of an actors system is represented by a lazy, n-ary tree. Each node in

the tree represents a potential computational state. The root node is the start state, which

represents the initial con�guration of the actor system. The branches from the root node

represent the transitions to next states possible when the actor program begins execution.

During the execution of a program within an actor system, a transition from the current

state to the next state in the computation space is de�ned as the random selection of one of

the existing branches (out of all the possible branches) leading from the current state. Since

this is a lazy tree, the transition branches not chosen lead, in a sense, to unexplored leaf

nodes in the computation space.

In general, con�gurations reached during an actor system's computation are represented

in the actor system's computation space by those nodes in the lazy, n-ary tree which have

children. The only exceptions to this rule are nodes which represent the current con�guration

or the �nal con�guration of an actor system. In the case of a non-�nal, current con�guration

node in the computation space, children will be added to that node as computation proceeds.

Each level of the tree represents a computational step. At every level of the tree, the

number of states is �nite. Despite this �niteness at each level, in�nite computation spaces

are possible, and must be a consequence of in�nite depth. Formally, we can state that

12

Theorem 1 If the computation space of an operational semantics is represented by a lazy,

in�nite tree, with a �nite number of children for each node, then a path of in�nite length can

be chosen, level by level, by a transition function capable of navigating the entire computation

space of that operational semantics.

Proof 1 This is a direct result of K�onig's In�nity Lemma which states that, if a tree is

in�nite and each node has a �nite number of children (possibly zero), then there exists at

least one path of in�nite length.

The traversal of the computation space represents the actual history of computation

which has occurred during an actor program's execution in the actor system. This traversal

is also called a trace, and will be formally de�ned in section 3.2. Since the traversal of the

computation space takes place in a lazy, n-ary tree, the traversal path can be thought of as a

lazy list. This is important because a lazy list (a list with states) provides a mechanism for

an observer of the computation to traverse the list at a pace independent of other observers,

and the computation itself. The only restriction on the pace of an observer's traversal is that

it cannot exceed that of the actual computation.

Now that the history of computation within the operational semantics of an actor system

has been explained, the concept of a view of the computation can be presented. Observers of

a parallel or distributed system see their own view of the computation. This phenomenon is

a direct consequence of the theory of relativity [12]. Views of a computation are represented

on a more granular level than the history of a computation. Views are at the event level in

this semantics; computational history is at the parallel event level.

Reasoning about computation in a PDS requires a computational model which provides

a mechanism for maintaining the clear separation between the history of a computation and

that computation's views. The operational semantics for actors being de�ned in this chapter

addresses this separation.

3.2 De�nitions and Data Structures

Direct observation of an actor program is problematic, impractical, and not conducive to

reasoning about actor systems in general. Limitations of human observation include resource

availability, endurance, and consistency (both rate and reproducibility). Furthermore, even if

these limitations do not exist, the physics of views dictates an over-speci�cation of the order

of computation within parallel and distributed systems. For all these reasons, when we wish

to reason about a particular actor system, S, we must develop a satisfactory model. The

model presented in this chapter is denoted S, and the data structures for S are described

below. The bar notation is used to denote elements in the model S which correspond to

elements in the actor system S. Formally, S is represented by the pair:

S = h �, �i,

where:

13

� represents the computation space of S, and

� represents the set of views of the computation within �.

The ith view of computation in �, denoted �i , contains the computational events observed

by the ith observer. � is an n-ary tree of state nodes, and a lazy data structure. The structure

and content of � rely on the following de�nitions and notation:

De�nition 2 (actor) An actor is a computational agent that has a behavior and is uniquely

identi�ed by its mail queue address.

De�nition 3 (actor machine) An actor machine is an instance of an actor and its current

behavior, bound to a particular element of that actor's mail queue.

De�nition 4 (task) A task is the content of a message sent to a designated recipient (an

actor) that is uniquely identi�ed by its task id.

Given the above de�nitions, we can de�ne the con�guration of S at time t to be the

contents of the following two sets:

1. A is the set of active actors. This set contains actor machines still performing compu-

tation within S.

2. T is the set of active tasks. This is the set of undelivered messages within S.

Both A and T from S have counterparts in S. De�nitions of A and T will be given later in

this section.

The computation space of S, denoted �, consists of all possible con�gurations reachable

from the initial con�guration of S. Each con�guration at some time t in S corresponds to

at least one state in �. Root node � corresponds to the initial con�guration in S. The

one-to-many relationship between con�gurations in S and states in � re ects only the mul-

tiple computational paths possible, not additional or di�erent computational power. These

multiple paths are due to the nature of parallel and distributed computation. Since S is a

model, the states in � carry additional information to facilitate the operational semantics

being de�ned. A state, �, within C is represented by the 5-tuple hM; A; T ; P ; �nexti,

where:

M is the set of mail queues for the actors in S.

A is the set of actor machines. This corresponds to A in S.

T is the set of tasks. This corresponds to T in S.

P is the set of parallel events.

�next is either unde�ned, or the state to which computation next proceeds, as assigned

by the transition function.

14

Except for the transition function, which will be de�ned in the next section, enough data

structures have been described to present the following de�nitions and decidable predicates:

De�nition 5 (trace) The trace of S is the traversal of S's computation space, starting

from the root node �, and progressing through all subsequent �'s chosen by the transition

function during computation.

Finally, we present decidable predicates in Pact that are useful for reasoning about PDS

computation. Identifying consumed tasks is not observable, since task consumption is internal

to an actor machine. Task consumption is, however, decidable for an actor machine. We

de�ne the consumed function formally as follows:

De�nition 6 (consumed(�)) Boolean function consumed returns true if actor machine

� has consumed its task, and returns false otherwise. This is easily decided by comparing

elements init and cont of �. If init and cont are syntactically equal, then � has not begun

its computation, and thus consumed returns false.

We de�ne two states to be equivalent (�=) if their respective M, A, and T sets are

identical. Formally:

De�nition 7 (�i �= �j ) �i �= �j () (�i :M = �j :M)V(�i :A = �j :A)

V(�i :T = �j :T )

During computation, S may enter one or more states of computational quiescence. Typ-

ically, computational quiescence is the result of S waiting for an incoming task from the

environment. These periods of time can be detected by following the trace of S, searching

for consecutive, computationally equivalent states.

The notion of an end of computation for S in Pact is not practical. Candidates for this

condition include traces of S in a current state of computational quiescence. In general,

it is not decidable whether S, in a current state of computational quiescence, is also in

an end of computation state. We cannot know whether S ever receives another inbound

task. Furthermore, even if S is in a current state �cur that contains no remaining actors

performing computation, no tasks, and no actor machines waiting for inbound tasks; �curcould still be acting as a task conduit for its environment. Inbound tasks that immediately

become outbound tasks in S constitute meaningful computation.

Earlier, A and T were de�ned in terms of actor machines and tasks. Their counterparts in

S, A and T , have been introduced as two of the parts comprising the 5-tuple that represents

a state, �, in S. M contains the mail queues of the actors whose actor machines are in A.

In particular, the ith actor's mail queue in M, denoted mi, contains the tasks delivered to

actor mi. With these as a basis, we can now provide de�nitions for model actor machines

and tasks in S.

Every actor machine instance of mi in A is bound to its own unique element of mi. For-

mally, actor machine �, an element of A, is represented by the 3-tuple h mi[loc], init, conti,

15

where mi[loc] is the element loc in mail queue mi withinM to which � is bound, init is the

initial behavior of �, and cont is the current continuation behavior of �.

Formally, model task � , an element of T in �, is represented by the 3-tuple h tid, mi, �i,

where tid is the unique task identi�er, mi is the task recipient (an actor's mail queue

within M), and � is the communication (message content). Set T can be divided into

two subsets: the set of inbound tasks, inboundtasks(T ;M), and the set of outbound tasks,

outboundtasks(T ;M). An inbound task is a task � whose recipient is an actor whose mail

queue mi is in M; otherwise � is an outbound task. We formally de�ne helper functions

inboundtasks() and outboundtasks() in Appendix A.3.

Now that the representations of actor machines and tasks comprising A and T within a

state, �, have been de�ned, discussion returns to the events in P. The formal de�nition of

an observable event is as follows:

De�nition 8 (observable event) An observable event is a task that has been sent by, or

delivered to, an actor.

Since we are only concerned with observable events in this paper, all events to which we

refer are observable. An event, ", is represented by the pair h Etype , � i, where values for Etype

are either ES for a sent task or ED for a delivered task. Thus, P in � is a set of instances of

the two types of sequential events.

There is an important derivative relationship between these two elements. In an applied

sense, P is a special derivative of T ; it represents the changes in T with respect to time.

Time in Pact is measured discretely by the transitions from one state to the next. Speci�cally,

events in P of type ES represent those � 's added to T in the last transition; events in P of

type ED represent those � 's removed from inboundtasks(T ;M) in the last transition. Since

P is derivable from T , it is not necessary to represent P explicitly in �. However, it is useful

to maintain P within each � to facilitate the construction of views.

It is now possible to de�ne �, the set of views. View �i corresponds to the ith observer.

The sequence of "'s contained in �i constitutes the ith observer's view of the trace. Concep-

tually, observer i is an entity who constructs �i via successive calls to the view function. The

view function will be presented in the next section.

The lazy, n-ary tree comprising � is an elegant data structure, supporting the guidelines

of operational semantics for S, while at the same time simplifying function de�nitions, which

are presented in Section 3.3. Speci�cally, the structure has the following characteristics:

� It is a self-navigating data structure.

� The trace represents the true history of computation, distinct from any view of

computation.

� Observers' views of computation may proceed at a pace independent of actual

computation and of each other.

� Views of computation may commence before � is fully calculated.

16

� Views of computation will not overtake actual computation.

The de�nitions and data structures presented comprise S. The next data structure, �, is

not part of S, but it supports the meaning function presented in Section 3.3. The meaning

function returns a set of possible meanings for an actor machine's computation. The formal

de�nition of meaning is as follows:

De�nition 9 (meaning) The meaning of actor machine �'s computation from time t to time

t+1 is information consisting of �'s remaining computation, the (possibly empty) set of new

actors created, the (possibly empty) set of new tasks created, and �'s (possibly speci�ed)

replacement behavior.

In Pact , we de�ne a meaning structure � to represent one of the many possible meanings of

�'s computation, and represent � by the 5-tuple h �cont , Mnew , Anew , T new , Arepl i. Element

�cont represents � updated with its new continuation. The sets Mnew Anew , and T new are

the sets of new mail queues, new actor machines, and new tasks created by �'s computation.

Element Arepl is either the empty set, or a singleton set containing �'s replacement actor

machine.

Using these de�nitions and data structures, Section 3.3 presents the functions which

generate C and support views of computation within S.

3.3 Functions

This section outlines the functions of our operational semantics, and rely heavily on the

de�nitions and data structures presented in section 3.2. Actual details of the mappings and

algorithms for all of these functions appear in Appendix A.

We assume the existence of an actor meaning function Am that abstracts away the details

of actor machine execution. Function Am takes as its input argument an actor continuation,

cont. Function Am returns a �nite set of meanings for a given actor machine. The set of

meanings returned by Am represents all the possible continuations of cont. This set must be

�nite since the language of an individual actor machine does not permit in�nite execution.

From Am, we construct the Pact meaning function F� given in Appendix A.2. Function

F� maps an actor machine � to a meaning of �'s current behavior. Function F� randomly

chooses one meaning for �'s computation from the set of all possible meanings of �'s current

continuation, cont.

In Pact , computation proceeds by calling the transition function, F�. The transition

function is itself composed of three functions: the inbound tasks function Fin , the outbound

tasks function Fout , and the generate children function G. These functions are formally

de�ned in Appendix A.2, and informally discussed below.

Function F� traverses � until it �nds a state whose �next is unde�ned . Such a state is the

current state of S, denoted �cur . Function F� assigns to �cur :�next the result of applying the

composition of Fout , Fin , and G to �cur . We consider the cumulative e�ect of applying each

17

of these functions to �cur , in turn, elaborating the next computational state in the trace of

S.

The innermost function applicationFout(�cur ) returns a new state �cur0, in which a random

subset of outbound tasks is removed from T , P is empty, and the remaining elements are

unchanged from �cur . In the case where no outbound tasks exist in �cur , T remains unchanged

in �cur0. Set P in �cur

0 is empty because forwarding outbound tasks beyond S does not

constitute an observable event; these tasks were previously observed as sent, and have yet to

be delivered.

The middle function application Fin(�cur0) returns a new state �cur

00, in which a random

subset of inbound tasks is chosen from the environment and added to T , P is empty, and the

remaining elements are unchanged from �cur0. In the case where no inbound tasks exist from

the environment, state �cur00 remains unchanged from �cur

0. Notice that P remains empty in

�cur00 because tasks added to T from the environment do not constitute observable events;

these tasks were already sent from some other location in the environment, so it is too late

to observe such tasks as sent within S.

The outermost function application G(�cur00) returns the elaborated �next of �cur

00, which

represents the random choice of a next state, from among all possible next states, in the trace

of S. Function G constructs its return state based on a random selection of inbound tasks T r

to deliver, the delivery of those tasksMdel(T r )

, and the subsequent random selection of eligible

actor machines Ar to make computational progress. The set Mdel(T r )

is constructed by

removing those mail queues fromM to which tasks will be delivered, then adding back those

mail queues with their delivered tasks. An eligible actor machine is an � whose message state

is delivered or consumed, and whose current continuation represents un�nished computation.

The set m of randomly chosen meanings is obtained from applying F� to each � in Ar . The

speci�cation of M0, A

0, and T

0is tedious but straightforward and follows this paragraph's

discussion. The speci�cation of P0warrants further attention. Set P will be empty regardless

of any inbound or outbound task activity in T that results from the two innermost function

applications Fout and Fin . Set P0includes events of type ES and ED that derive from the

meanings of actors in Ar that created new tasks � or had tasks from T r delivered to them.

Function F� traverses its input view � simultaneously with the corresponding trace of

tree �, until � has been traversed. Next, F� calls function V to continue traversing the trace

of �, for some random number of transitions limited so as not to overtake the current state

of computation. While V continues to traverse �, it also constructs a subsequent view �0 to

return to F�. For each state traversed, the corresponding �i in �0 is a random linearization

of a random subset of P. Upon return, F� appends �0 to the end of �, thus constructing the

new view.

3.4 Perspective

It is not surprising that there are some similarities between the operational semantics pre-

sented in this chapter and the work by Agha [4]. Our objectives are di�erent but share much

18

in common, since actors is a PDS. For more details of our semantics, see [28]. For more

recent work by Agha et al., see [3]. As discussed in section 1, we are not speci�cally de�ning

a computational model for actors; but are concerned with developing a model that promotes

reasoning about PDS computation in general. The remainder of this section points out some

of the resultant similarities and di�erences between our model and Agha's original model [4].

Section 4 discusses our continuing research.

States in both of our models consist of actors and tasks, and both models utilize concate-

nated strings of integers as identi�ers (or tags) for actors and tasks. Where the models di�er

is in granularity of execution, support for representing views, and in some cases, terminology.

For example, quiescence is used in [4] to describe a condition where no further execution

will occur unless an external task is received. Our model also describes this condition. But we

further distinguish an end of computation condition. It may not be possible in the strictest

sense for an actor system to reach this state, but it is possible in general PDS computation.

The closest actor equivalent would require an actor to not specify a replacement behavior

(without default replacement behaviors), or for an actor to be able to specify an empty

replacement behavior. Under these circumstances, it is possible for a state to be reached

which �nds no actors waiting to receive external tasks. In this case, we de�ne the end of

computation condition.

In one sense, our model is less granular than Agha's, who uses denotational semantics

to describe the detailed evaluation of the minimal actor language constructs. Now that this

detail has been demonstrated for actors, we de�ne a meaning function and substitute it in

our model to perform this function for any language of interest. This allows the focus of our

model to derive from observable events, rather than actor (or any other) language constructs.

In any PDS, messages are at the heart of observable computation, along with the need for

coordination, which messages support.

In another sense, our model is more granular. This concerns the messages themselves,

or tasks. Our model distinguishes between messages sent, delivered, and received. Agha's

semantics distinguishes tasks to be either unprocessed or processed. This is also an example

of important di�erences in terminology. In our model, tasks that have been delivered are

removed from the set of tasks, and placed into the recipient actor's mail queue. Delivery in

our model does not mean that the recipient actor has begun to process its message, only that

it is eligible to do so.

Our transition function supports more than one task at a time being chosen for delivery,

and potential processing. Consequently, the transition function in our model also supports

simultaneous actors making computational progress. This capability required explicit data

structures to support not only the parallel events, but also the views of these events. Traces of

computation are now expressed in terms of sets of events (tasks) and corresponding views in

the more granular, but only partially ordered, view queues. While no one view fully speci�es

a trace, any view may be easily veri�ed against its corresponding trace for correctness.

19

Chapter 4

Proposed Future Work

After surveying the literature to �nd representative PDSs [26, 13, 30, 29, 10] and research

contributions in the area of PDS computation [18, 14, 9, 15, 8, 27, 4, 6, 16, 5] we arrived at two

conclusions. First, much research has been invested into the goal of developing \ideal" PDS

models. Each model is based on its own particular set of assumptions emanating from the

requirements imposed by that model's authors. Little attention has been given to developing

a uni�ed model for PDS computation, one which provides a consistent level of abstraction

for reasoning about PDSs in general.

Second, among all the models we studied, actors stood out as having the elegance and

power to be the focus of the preliminary stages of our work on this paradigm. The challenge is

to distill the di�erences between representative PDSs (speci�cally actors, Java, CORBA, and

HLA) into parameters, and develop a general model of computation. ParaDOS will be this

general model, which we view as the primary contribution of our research. The parameters

for ParaDOS must be chosen carefully so that the model can be used to reason about a broad

range of PDSs.

The remaining sections of this chapter present the di�erent facets of the proposed future

work. Section 4.1 contains a discussion of the overall goals of ParaDOS. Section 4.2 presents

a taxonomy of PDS features. Section 4.3 hypothesizes about ParaDOS and discusses the

model's stages of development. Finally, Section 4.4 gives a characterization of the semantics

being developed.

4.1 Goals

The overall goals for ParaDOS are as follows:

� ParaDOS should be an expressive model at a level of abstraction appropriate for rea-

soning;

� ParaDOS should promote reasoning about PDS computation, providing a rich frame-

work for proving properties about speci�c PDSs; and

20

� ParaDOS should be a general, unifying model of PDS computation, capable of modeling

individual PDS behavior through its parameters.

ParaDOS utilizes operational semantics because it is our contention that a computational

model based on operational semantics is the appropriate tool to realize our goals. Operational

semantics provides the freedom to de�ne a computational model at an appropriate level of

abstraction. Thus, the desired level of abstraction will be one which makes ParaDOS both

expressive and appropriate for reasoning about the classical problems discussed in Section 2.2.

The third goal listed above represents our ultimate aspirations to de�ne ParaDOS to be a

general, unifying model of PDS computation. Careful selection of the level of abstraction for

ParaDOS is an important step toward de�ning its parameters, and thus essential to realizing

ParaDOS's long term goal.

4.2 Taxonomy of PDS Features

There are two sets of choices involved in de�ning ParaDOS. These are the features to be

modeled and the PDSs to be considered for ParaDOS instantiation. This section presents

our initial decisions. For discussion and reference purposes, we introduce Table 4.1 (page 22)

to summarize this information. Table 4.1 catalogs which PDSs possess which native features.

The information contained in each row of Table 4.1 pertains to an individual PDS feature

while the information in each column pertains to a particular PDS. The table represents a

work in progress, and is almost certain to change and evolve during the course of our research.

Its content was di�cult to freeze for purposes of completing this paper. I must resist the

temptation to attempt to create the perfect table from which to build ParaDOS, because

giving in to this temptation might preclude me from any further ParaDOS development!

The table is therefore frozen at this time so that its current contents may be described, but

this table is a living entity whose contents remain open for discussion.

The �rst row of Table 4.1 contains the feature transactions. Transactions are either

supported or not supported in a PDS. For our purposes, a transaction is the composition of

more than one event into a single, atomic event. The semantics of a transaction prescribe

that a transaction occurs only when all the individual events that comprise it occur; there are

no partial transactions. The implication for PDSs that endeavor to implement transactions

as a native feature is that some sort of rollback-commit or replication strategy is required.

The next two rows of Table 4.1 are concerned with the two basic types of messages as

native PDS features: asynchronous and synchronous. The mechanics of asynchronous and

synchronous messages are di�erent, but both are computationally equivalent since each can

simulate the other. In the case of asynchronous messages, the sender of a message may

immediately resume further processing, regardless of whether the receiver has received the

message. In the case of synchronous messages, the sender of a message must wait until the

receiver receives (or receives and processes, as is the case for Java RMI) the message before

the sender may resume processing.

21

Actor PDSs Linda Java PDSs CORBA v3.0

Category: Actor- Tuple Java- ORB/ HLA/

Native Feature Actors Space Space RMI Space Jini IIOP RTI

Transactions:

Supported N N N N Y Y Y Y

Message types:

Asynchronous Y Y Y N Y Y Y Y

Synchronous N N N Y N Y* Y* ?

Message Intermediary

Characterization:

Employed N Y Y N Y O Y Y

Passive N Y Y N Y Y N N

Active N N N N N Y Y Y

Message Destination

Speci�cation

(One to:)

One (precisely) Y Y N Y N Y Y Y

Any (zero or more) N Y Y N Y Y N N

Many N N N N N N N Y

Message delivery:

Guaranteed Y Y N N N N N O

Order-preserving N N N Y N Y* Y* O

Key to PDS Y - Yes: a native feature

Feature Codes: N - No: not a native feature

O - Optional: a native, but optionally supported, feature

Y* - Yes: but in conjunction with other Y* features

Table 4.1: Table of Features versus PDSs

22

Another important characterization of a PDS is whether it employs a messaging interme-

diary, and if so, what kind of role the intermediary plays: active or passive. In a PDS that

does not use intermediaries, processes exchange handles with each other to facilitate direct

communication. An active intermediary in a PDS assumes the role of a process in its own

right, is generally known to all other executing processes that have a need to communicate,

and is often responsible for a sent message's routing and delivery. A passive intermediary

usually takes the form of a common, shared memory space accessible by a PDS's executing

processes, according to some agreed-upon protocol. These characteristics are represented by

the next three rows in the table.

Following the rows pertaining to message intermediaries in Table 4.1 are three rows de-

picting the possible message destination speci�cations in PDSs. These speci�cations are

one-to-one, one-to-any, and one-to-many. Broadcast messages are not being considered in

this taxonomy because they are not scalable in the broadest sense, but more importantly be-

cause they can be modeled computationally by one-to-any messages. In PDSs that support

one-to-one messages, the sender knows the handle of its message's intended recipient, and has

the capability to invoke a send command passing some message speci�cally to that recipient.

One-to-any messages can be viewed like a blackboard architecture, where the sender writes a

message on the blackboard (some shared memory), and zero or more receivers may read the

message from the board if interested. One of these receivers may even erase the board, thus

preventing further receipt of that message. With one-to-many messages, the sender need not

have any knowledge of the receivers. One-to-many messages are messages that are sent by a

designated sender to a group of designated receivers. In the case of an active message inter-

mediary, the sender need not know who the receivers are, but someone { the intermediary {

must keep track of who the receivers are for a message to be considered one-to-many.

The �nal two rows in Table 4.1 are concerned with aspects of message delivery: guaranteed

and order-preserving. The guarantee of message delivery is self-explanatory. The order-

preserving feature also has a straight-forward meaning, relative to each sender: the order

messages are received is the same as the order in which they are sent.

The columns of Table 4.1 contain the PDSs we chose to study toward the development

of ParaDOS. It so happens that the PDSs, like the features in the table, also fell into cate-

gories. There are four PDS categories in Table 4.1: two academic, and two commercial. The

academic PDSs are two actor models, Actors and ActorSpace, and Linda's Tuple Space. The

commercial PDSs consist of three Java PDSs and two parts of the CORBA 3.0 speci�cation.

The Java PDSs are RMI, Javaspace, and Jini; the CORBA PDSs are the ORB and IIOP

speci�cation, and the HLA/RTI speci�cation. The signi�cance of inclusion for these PDS

choices was discussed in Sections 2.1.1 and 2.1.2 of this paper.

4.3 The Model

The focus of my dissertation work is the continuing development of the ParaDOS model,

working toward a unifying model for parallel and distributed computation. This section

23

discusses the current state of ParaDOS, and its proposed future stages of evolution, which

involve introducing parameters into the model. These parameters will provide ParaDOS with

the capability of further instantiation into the ActorSpace, Java, and CORBA models of

parallel and distributed computation. My hypothesis is that a parameterized computational

model employing operational semantics can provide both

� a framework for conveying the inherent nature of parallel and distributed computation,

and

� an expressive and e�ective means for proving properties about the systems it models.

Ultimately, a taxonomy of PDSs which can be instantiated by ParaDOS will be developed.

The taxonomy will be a tree with branches distinguished by their corresponding parameter

values.

The present state of my progress on ParaDOS is that I have completed an operational

semantics for actors. As previously discussed in Section 2.1.1, my initial work concentrated

solely on actors, a logical starting point. While actors has proven to be a bene�cial PDS from

a research standpoint, it is not at this time an industry standard. Therefore, PDSs more

prevalent in industry must also be modeled. The present operational semantics for actors

will be one important instantiation of the eventual ParaDOS.

Future stages for ParaDOS involve augmenting its PDS modeling capabilities from ac-

tors to other PDSs. These new modeling capabilities will be realized by introducing new

parameters and parameter values into ParaDOS. The PDSs that need to be incorporated

into ParaDOS are from those previously discussed in Section 2.1.2 of this paper. At this

time, the planned order of consideration for inclusion in ParaDOS is as follows: ActorSpace,

Java RMI, JavaSpace, Jini, CORBA's ORB and IIOP, and within CORBA, the HLA/RTI

speci�cation. Not all of these PDSs will be examined at the same level of detail. For each

new PDS included in ParaDOS, I will focus on the native features with salient di�erences

from those features already integrated in the model.

4.4 Characterizations

The discussion in section 4.3 of this paper (on the present and planned future stages of

ParaDOS) was essential, but only scratches the surface. Our earlier discussion belies the

true nature of this research proposal. Beneath the seemingly disjoint sequence of operational

semantics to be developed for chosen PDSs lies the forming of a three-dimensional structure

of computational models whose essence is one of the underpinnings of computer science: the

ability to build new models from existing models. The focus of this section is to more fully

describe our research plan for giving a characterization of the operational semantics that will

be developed during the course of this research.

Existing PDSs provide a choice of frameworks for the implementation of parallel and

distributed computation. With this thought in mind, we chose the PDSs in Table 4.1 to form

24

the basis of our research. We will be considering these PDSs from three di�erent levels of

abstraction. The lowest level of abstraction is the PDSs themselves; the next higher level

of abstraction consists of the individual operational semantics for each of these PDSs; and

�nally, the highest level of abstraction is the unifying model, ParaDOS. We discuss each level

in turn.

The PDS level of abstraction must be considered if one's goal is to develop a unifying

model of PDS computation, a model capable of individual, speci�c PDS instantiation. We

consider this level of abstraction for two reasons. First, each PDS is its own abstraction

of parallel and distributed computation, providing its own distinct framework. Second, it

is the aggregate of individual PDS abstractions that determines the capabilities required of

ParaDOS. One of the challenges at the PDS level of abstraction is that each chosen PDS has

its own unique legacy, which may or may not include a formal semantic model.

The operational semantics for actors we developed in Chapter 3 of this paper, as well

as those still to be de�ned for the remaining PDSs from Table 4.1, are at the next higher

level of abstraction. At least two of the models (possibly more) at this level will evolve

through two forms, beginning as an individual operational semantics for a particular PDS,

then eventually becoming an instantiation of ParaDOS for that PDS. As ParaDOS matures,

it may be possible for some operational semantics to be de�ned directly through a new

ParaDOS instantiation. At this second (middle) level of abstraction, concern will be for the

individual operational semantics form of the models; the instantiation of the ParaDOS form

of the models will be the concern of the unifying model level of abstraction.

Characterization of an operational semantics de�ned at the second level of abstraction

depends in part on the legacy of its corresponding PDS on the �rst level of abstraction. If its

PDS already has a semantic model to compare against, an equivalence proof must be given.

If its PDS has no such model, then arguments for soundness and completeness of the new

operational semantics will have to su�ce in lieu of a proof. Our operational semantics for

actors falls into the former category, requiring an equivalence proof. The proof still needs

to be worked out formally, but a sketch of the approach is presented in Appendix B. In

either case, discussion must include an explanation for the level of abstraction (granularity)

adopted by an operational semantics for its PDS. This discussion should include what level

of computation is explicitly modeled, and what is not modeled. Finally, we should give an

explanation of when to use each operational semantics, as well as examples of how to each

operational semantics.

Characterization of the operational semantics for actorspaces will be a similar process to

that of actors. An operational semantics for actorspaces was developed by [7], and is the

appropriate model to use as the basis for a characterization of my semantics. Formal models

of computation for Java PDSs are more scarce, but a characterization of semantics for these

PDSs may �nd a basis in work by [20, 25]. The most challenging operational semantics to

characterize will be those developed for the CORBA and HLA PDSs, though by this time

other acceptable approaches may present themselves.

Presumably, the \when" and \how" an operational semantics from our second level of PDS

25

abstraction is used will relate to deciding interesting properties and proving theorems about

its corresponding PDS. For help in choosing interesting properties, or deciding what theorems

we want to prove for a PDS, we can turn to the classic problems discussed in section 2.2.

For example, it is interesting to know for a particular PDS whether deadlock is possible

or impossible. What about in�nite postponement? Exercising an operational semantics on

PDS code for the dining philosophers problem or the producer-consumer problem could also

provide insightful counterexamples. Proofs that can't be shown by counterexample are more

challenging. These operational semantics could demonstrate the meaningful workings of

resource management, resource allocation, and fairness for a particular PDS. Finally, these

operational semantics could be exercised to demonstrate PDS implementations of critical

section mechanisms like semaphores, monitors, and message passing.

Turning our attention to ParaDOS, the third level of PDS abstraction, we �nd ourselves

moving away from the anecdotal evidence of what ParaDOS is capable of modeling. We need

a more powerful mechanism to express the modeling power of ParaDOS. The term orthog-

onality, used in the programming languages community, is concerned with the interactions

between a model's parameters. Speci�cally, which combinations of parameter values are

valid, valid but not meaningful, or invalid? Orthogonality also addresses any dependencies

that may exist between parameters.

We would like to be able to prove orthogonality for ParaDOS. This is a potentially un-

reachable goal. There is an expectation that these proofs may in fact be too di�cult to

be contained in my topic. It is likely that there will simply be too many combinations of

parameter values to be manageable. Even if this goal is unreachable, the road leading toward

proving orthogonality for POSPDS is still worth traveling. For example, it could lead to valid

and meaningful combinations of parameter values that do not correspond to any instantia-

tions of the PDSs explicitly modeled. If so, there are two possibilities. One possibility is that

this new-found combination corresponds to a real-world PDS that wasn't explicitly modeled.

This is certainly plausible, but not very exciting. The other possibility is that a combination

of parameter values is found that has desirable properties but does not correspond to any

PDS implementation. In this case it might be interesting to implement a proof of concept to

validate the properties predicted by the model.

26

Bibliography

[1] G. Agha and C. J. Callsen. Actorspace: an open distributed programming paradigm.

ACM SIGPLAN Notices, 28(7):23{32, July 1993.

[2] G. Agha and C. J. Callsen. Open heterogeneous computing in actorspace. Journal of

Parallel and Distributed Computing, pages 289{300, 1994.

[3] G. Agha, I. A. Mason, S. F. Smith, and C. L. Talcott. A foundation for actor computa-

tion. Journal of Functional Programming, 7(1):1{72, 1997.

[4] G. A. Agha. ACTORS: A Model of Concurrent Computation in Distributed Systems. The

MIT Press Series in Arti�cial Intelligence. The MIT Press, Cambridge, Massachusetts,

1986.

[5] G. R. Andrews. Paradigms for process interaction in distributed programs. ACM Com-

puting Surveys, 23(1):49{90, Mar. 1991.

[6] A. D. Birrell and B. J. Nelson. Implementing remote procedure calls. ACM Transactions

on Computer Systems, 2(1), Feb. 1984.

[7] C. J. Callsen. Open Distributed Heterogeneous Computing. PhD thesis, Aalborg Univer-

sity, Denmark, 1994.

[8] K. M. Chandy, J. Kiniry, A. Rifkin, and D. Zimmerman. II: The Infospheres Infrastruc-

ture User Guide. California Institute of Technology, Pasadena, CA, 1.0fc edition, Aug.

1997.

[9] K. M. Chandy and J. Misra. Parallel Programming Design: A Foundation. Addison-

Wesley Publishing Company, Inc., 1988.

[10] Department of Defense, Defense Modeling and Simulation O�ce. Hla interface spec-

i�cation, version 1.3. WWW, Apr. 1998. DoD's HLA RTI Interface speci�cations,

http://hla.dmso.mil/hla/tech/ifspec/.

[11] E. W. Dijkstra. Hierarchical ordering of sequential processes. Acta Informatica, 1:115{

138, 1971.

27

[12] A. Einstein. The Theory of Relativity & Other Essays. MJF Books, New York, NY,

1950.

[13] J. Farley. JAVA Distributed Computing. The Java Series. O'Reilly, �rst edition, Jan.

1998.

[14] I. Foster and S. Taylor. Strand: New Concepts in Parallel Programming. Prentice Hall,

Inc., 1990.

[15] D. P. Friedman, M. Wand, and C. T. Haynes. Essentials of Programming Languages.

Massachusetts Institute of Technology, 1992.

[16] D. Gelernter. Generative communication in linda. ACM Transactions on Programming

Languages and Systems, 7(1), Jan. 1985.

[17] M. Hennessy. The Semantics of Programming Languages: An Elementary Introduction

Using Structural Operational Semantics. Wiley, New York, 1990.

[18] C. Hoare. Communicating Sequential Processes. Prentice-Hall International, UK, Ltd.,

UK, 1985.

[19] D. Howe. FOLDOC. URL http://wombat.doc.ic.ac.uk/. The Free On-line Dictionary

of Computing is edited by Denis Howe.

[20] B. Jacobs, J. van den Berg, M. Huisman, and M. van Berkum. Reasoning about java

classes: (preliminary report). In OOPSLA '98. Proceedings of the conference on Object-

oriented programming, systems, languages, and applications, pages 329{340, Oct. 1998.

[21] G. Kahn. Natural semantics. In F. Bandenburg, G. Vidal-Naquet, and M. Wirsing,

editors, Fourth Annual Symposium on Theoretical Aspects of Computer Science, volume

247 of Lecture Notes in Computer Science, pages 22{39, Berlin, 1987. Springer Verlag.

[22] P. Landin. The mechanical evaluation of expressions. The Computer Journal, 6(4):308{

320, Jan. 1964.

[23] M. Marcotty, H. Ledgard, and G. Bochmann. A sampler of formal de�nitions. Computing

Surveys, 8(2):191{276, 1976.

[24] G. Plotkin. A structural approach to operational semantics. Technical report, Computer

Science Department, Aarhus University, Aarhus, Denmark, 1981.

[25] Z. Qian. A formal speci�cation of java virtual machine instructions for objects, methods

and subroutines. In J. Alves-Foss, editor, Formal Syntax and Semantics of Java, volume

1523 of LNCS. Springer Verlag, 1998.

[26] J. Siegel. CORBA Fundamentals and Programming. John Wiley & Sons, Inc, New York,

1996.

28

[27] K. Slonneger and B. L. Kurtz. Formal Syntax and Semantics of Programming Languages:

A Laboratory Based Approach. Addison-Wesley, Reading, Massachusetts, 1995.

[28] M. L. Smith, R. J. Parsons, and C. E. Hughes. Operational semantics for actors: Toward

a parameterized model for reasoning about parallel and distributed computation. Tech-

nical Report CS-TR-99-05, School of Computer Science, University of Central Florida,

1998.

[29] Sun Microsystems. Distributed event speci�cation. WWW, July 1998. On Sun Microsys-

tems, Inc.'s java.sun.com website. http://java.sun.com/products/jini/specs/index.html.

[30] Sun Microsystems. Javaspace speci�cation. WWW, July 1998. On Sun Microsystems,

Inc.'s java.sun.com website. http://java.sun.com/products/jini/specs/index.html.

[31] P. Wycko�, S. W. McLaughry, T. J. Lehman, and D. A. Ford. T spaces. IBM Systems

Journal, 37(3):454{474, 1998.

29

Appendix A

Function De�nitions

This appendix contains all the function de�nitions discussed in Section 3.3 of this paper.

A.1 Function Types

This appendix section presents the type de�nitions for the Pact functions presented in the

remainder of Appendix A. Three of the Pact types presented below are left unspeci�ed. Type

msg represents the data domain of messages and actors, and the semantics is parameterized

with respect to this domain. The type for the continuation of an actor, beh, is spec�c to the

particular actor meaning function and is thus unspeci�ed in Pact. The only requirement for

type tidtype is that it be possible to generate unique elements for all tasks within the model.

� state mailqSet � actmachSet � taskSet � parEventSet � state

M mailqSet P (mailq)

A actmachSet P (actmach)

T taskSet P (task)

P parEventSet P (seqEvent)

mi mailq list(task)

� actmach mqloc � beh � beh

� task tidtype �mailq �msg

" seqEvent etype � task

mi[loc] mqloc mailq � int

beh continuation (unspeci�ed)

tid tidtype task identi�er (unspeci�ed)

� msg message content (unspeci�ed)

Etype etype fES;EDg

� meaning actmach �mailqSet � actmachSet � taskSet � actmachSet

� view list(ROPE )

� ROPE list(seqEvent)

30

A.2 Pact Functions

We de�ne the meaning function as follows:

F� : actmach �! meaning

F�(hmi[loc]; init; conti) =

� where

� 2 fh�cont ;Mnew ;Anew ; T new ;Arepl i j

Am( cont) yields �cont ;Mnew ;Anew ; T new ;Arepl g

We de�ne the transition function as follows:

F� : state �! state

F�(hM; A; T ; P; �nexti) =

if �next unde�ned

hM; A; T ; P ; G(Fin(Fout(hM; A; T ; P; �nexti)))i

else

hM; A; T ; P ; F�(�next)i

We de�ne the outbound task function as follows:

Fout : state �! state

Fout(hM; A; T ; P; �nexti) =

let T sub � outboundtasks(T ;M)

in hM; A; T � T sub ; ;; unde�nedi

We de�ne the inbound task function as follows:

Fin : state �! state

Fin(hM; A; T ; P; �nexti) =

let Er � f� j � is from the environment g

in hM; A; TSEr; ;; unde�nedi

We de�ne the generate children function as follows:

G : state �! state

G(hM; A; T ; P; �nexti) = hM0; A0; T 0; P 0; �next0i where

�next0 is unde�ned, and

let T r � inboundtasks(T ;M)

in let Mdel(T r )

= (M� fmailqnamed(recip(�);M) j � 2 T rg)S

31

fdeliver(� ;mailqnamed(recip(� );M)) j � 2 T rg

in let Ar � eligacts

(A;Mdel(T r )

)

in let m = fF�(�) j � 2 Arg

in

M0=M

del(T r )

S SSSh�cont ;Mnew ;Anew ;T new ;Arepl i2m

Mnew

!

A0= (A�Ar )

S SSSh�cont ;Mnew ;Anew ;T new ;Arepl i2m

�f�contg

SAnew

SArepl

�!

T0= (T � T r )

S SSSh�cont ;Mnew ;Anew ;T new ;Arepl i2m

T new

!P0= P

S(hES; �i j � 2

SSSh�cont ;Mnew ;Anew ;T new ;Arepl i2m

T new

!)SfhED; �i j � 2 T rg

We de�ne the view function as a pair of functions, with F� calling V as follows:

F� : view � state �! view

F�(�; hM; A; T ; P; �nexti) =

if � empty

V (hM; A; T ; P ; �nexti)

else

append((head(�));F�(tail(�); �next))

V : state �! view

V (hM; A; T ; P ; �nexti) =

if hM; A; T ; P; �nexti unde�ned

()

else

let vr � P

in let � = list(vr)

in random choice of(append((�);V (�next)); or

(�)

A.3 Pact Helper Functions

We de�ne the inboundtasks() helper function as follows:

32

inboundtasks : taskSet �mailqSet �! taskSet

inboundtasks(T ;M) =

f� j � 2 TV9mi 2 M s.t. recip(�) = mig

We de�ne the outboundtasks() helper function as follows:

outboundtasks : taskSet �mailqSet �! taskSet

outboundtasks(T ;M) =

T � inboundtasks(T ;M)

A.4 dP act Functions

We de�ne the limited version of the transition function as follows:

F�̂: state �! state

F�̂(hM; A; T ; P; �nexti) =

if �next unde�ned

hM; A; T ; P ; F bin(hM; A; T ; P ; �nexti)i, or

hM; A; T ; P ; Fdout(hM; A; T ; P; �nexti)i, or

hM; A; T ; P ; �0i, where

�0 is derived from F�(�) where � 2 A

else

hM; A; T ; P ; F�̂(�next)i

We de�ne the limited version of the outbound task function as follows:

Fdout : state �! state

Fdout(hM; A; T ; P; �nexti) =

hM;A; T � f� rg; ;; unde�nedi where

� r 2 outboundtasks(T ;M)

We de�ne the limited version of the inbound task function as follows:

F bin : state �! state

F bin(hM; A; T ; P; �nexti) =

hM;A; TSf� rg; ;; unde�nedi where

� r is from the environment

33

Appendix B

Equivalence Proof

B.1 Proof Notation

B.1.1 AT Predicates and Helper Functions

Recall [s]a represents an actor a in state s, and a / M represents a message intended for

recipient actor a with contents M . We assume the existence of two predicates on an actor

state s, ready?(s) and busy?(s), that return true if an actor in state s is not busy computing

and ready to receive a new message, or busy computing in its current state, respectively.

The internal con�guration I of an AT state is a multiset of actors and messages in which

no two actors have the same name. Since actor replacement behavior di�ers between AT

and Pact , a one-to-many relationship exists between the actor machines in Pact and actors

in AT . For comparison purposes between respective AT states and Pact states, we assume

the existence of a helper function, ICfg(I), to �lter out those actors in I eligible for garbage

collection [3].

B.1.2 Pact Predicates and Helper Functions

Recall:

�p = hmk[loc]; init; conti, and

� r = htid ; mk; �i.

Function actname : actmach �! int

actname(�) = k

where k is from �:mk[loc]:

Function cont : actmach �! beh

cont(�) = �: cont:

Function content : task �! msg

content(�) = � :�:

Function recip : task �! int

recip(�) = k

34

where k is from � :mk:

Function newcont : actmach � beh �! actmach

newcont(�; ) =

�0 where

�0: cont = ;

�0:� = �: � :

Function deliver : mailqSet � task �! mailqSet

deliver(M; �) =

M0where

let k = recip(�) in

M0= (M�fmkg)

Sfappend(mk; � )g:

Function retrieveMsg : actmach �mailqSet �! actmach

retrieveMsg(�;M) =

�0 where

let C[ ] be the evaluation context from �: cont,

and k = content(deliveredtask(M; �)) in

�0: cont = replace C[ ] with C[k] in �: cont,

�0:� = �:�.

Function und? : mailqSet � actmach �! Bool

und?(M; �) =(True if �:mk[loc] in M Null;

False otherwise:

Function del? : mailqSet � actmach �! Bool

del?(M; �) =(True if �:mk[loc] in M not Null

V�: init = �: cont;

False otherwise:

Function cons? : mailqSet � actmach �! Bool

cons?(M; �) =(True if �:mk[loc] in M not Null

V�: init 6= �: cont;

False otherwise:

Function deliveredtask : mailqSet � actmach �! task

deliveredtask(M; �) = mk[loc]

where mk 2 MV� is bound to �:mk[loc]

B.1.3 Equivalence Relations

De�nition 10 (7�!cfg

) LetKAT

i=DD

IEE

�

�

andKdPact

j= �j , where �j = hM; A; T ; P ; �nexti.

Then KAT

i7�!cfg

KdPact

ji�

35

�8[s]a 2 ICfg(I) 9�p 2 A s.t. [s]a 7�!

act

�p

� V�8�p 2 A 9[s]a 2 ICfg(I) s.t. [s]a 7�!

act

�p

� V�8a / M 2 I 9� r 2 T s.t. a / M 7�!

msg

� r

�V �8� r 2 T 9a / M 2 I s.t. a / M 7�!

msg

� r

�V�8a 2 � 9�p 2 A s.t. actname(�p) = a

�V �8a 2 �:8�p 2 A:actname(�p) 6= a

�:

De�nition 11 (7�!act

) [s]a 7�!act

�p i�

if del?(M; �p)��a = actname(�p)

� W �a 2 fb j b = anon(actname(�p))g

��V�s = cont(retrieveMsg(�p ;M))

�:

else��a = actname(�p)

� W �a 2 fb j b = anon(actname(�p))g

��V �s = cont(�p)

�:

De�nition 12 (7�!msg

) a / M 7�!msg

� r i��a = recip(� r)

� V �M = content(� r)

�:

36

B.2 Theorem and Proof

Theorem 2 For all actor programs, pgm, let KAT

0 be the initial con�guration of pgm from

KATbig

(pgm), and KdPact

0 be the initial con�guration of pgm from KdPact

(pgm).

KAT

0

AT

=)� KAT i� KdPact

0

dPact

=)� KdPact

where

KAT 7�!cfg

KdPact

.

Proof: (=))

8i � 0:9j � 0: KAT

0

AT

=)i KAT

i

=) KdPact

0

dPact

=)j KdPact

j

VKAT

i7�!cfg

KdPact

j:

By induction on i.

Base: (i = 0)

i = 0 =) KAT

i= KAT

0 :

So, it su�ces to prove 9j � 0 s.t. KdPact

0

dPact

=)j KdPact

j

VKAT

0 7�!cfg

KdPact

j.

But KAT

0 is the initial con�guration of pgm in AT big .

=) KAT

0 =DD

IEE�

�

, where I contains one actor, [s]a, and no messages. Thus I = f[s]ag.

=) � = fag; KAT

0 's only receptionist; and � = ;, since initially, pgm has no knowledge

of external actors.

KdPact

0 is the initial con�guration of pgm in Pact .

=) KdPact

0 = �0 = hM; A; T ; P; �nexti.

=) P = ;, and initially, �next is unde�ned; and

M = fag,

A = f�pg, where (actname(�p) = a)V

(cont(�p) = s), and

T = ;.

From the de�nition of 7�!cfg

, w.r.t. KAT

0 and KdPact

0 , notice

[s]a 7�!act

�p satis�es the condition for actor correspondence,

message correspondence is true vacuously,

the condition for receptionists is true, since a 2 � and actname(�p) = a,

and the condition for external actors is true vacuously.

) By de�nition of 7�!cfg

, for i = 0; j = 0,

KAT

0 7�!cfg

KdPact

0 is true.

37

I.H.: Assume for some i � 0 steps,

KAT

0

AT

=)i KAT

iimplies 9j � 0, s.t.

KdPact

0

dPact

=)j KdPact

j

VKAT

i7�!cfg

KdPact

j.

I.S.: (Prove true for i+ 1 steps)

KAT

0

AT

=)i+1 KAT

i+1 =

KAT

0

AT

=)i KAT

i

AT

=)1 KAT

i+1, by de�nition ofAT

=).

By I.H. we know 9j s.t.

KdPact

0

dPact

=)j KdPact

j

VKAT

i7�!cfg

KdPact

j.

Consider cases for KAT

i

AT

=)1 KAT

i+1. Prove 9n � 0 s.t.

KdPact

j

dPact

=)n KdPact

j+n

VKAT

i+1 7�!cfg

KdPact

j+n.

38

Case 1a: create actor

� Let KAT

i=DD

Ii ; IEE

�

�

, KAT

i+1 =DD

Ii+1 ; IEE

�

�

, and KAT

i

AT

=) KAT

i+1,

where Ii = f[s]ag and Ii+1 = f[s]a; [s0]a; [t]bg.

� By I.H. and 7�!cfg

,

9�p 2 �j :A, s.t. [s]a 7�!act

�p .

� By de�nition ofAT

=), Am([s]a) yields f[s0]a; [t]bg

) By de�nition of F�, 9� 2 F�(�p), where

� = h�cont ;Mnew ;Anew ; T new ;Arepl i,

cont(�cont) = s0 (syntactic equality implies semantic equality),

Anew = f�rg,

actname(�r) = b, and

Mnew = fbg.

) [t]b 7�!act

�r .

� By de�nition of G, for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = �j :MSMnew ,

A = (�j :A� f�pg)Sf�contg

SAnew ,

T = �j :T ,

P = ;, and

�next is initially unde�ned,

where

[s0]a 7�!act

�cont , since cont(�cont) = s0, [s]a 7�!act

�p , and by de�nition of �cont .

) By de�nition of 7�!cfg

, KAT

i+1 7�!cfg

KdPact

j+1 .

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 1a.

39

Case 1b: send message

� Let KAT

i=DD

Ii ; IEE

�

�

, KAT

i+1 =DD

Ii+1 ; IEE

�

�

, and KAT

i

AT

=) KAT

i+1,

where Ii = f[s]ag and Ii+1 = f[s]a; [s0]a; b / Mg.

� By I.H. and 7�!cfg

,

9�p 2 �j :A, s.t. [s]a 7�!act

�p .

� By de�nition ofAT

=), Am([s]a) yields f[s0]a; b / Mg

) By de�nition of F�, 9� 2 F�(�p), where

� = h�cont ;Mnew ;Anew ; T new ;Arepl i,

cont(�cont) = s0 (syntactic equality implies semantic equality),

T new = f� rg,

) b / M 7�!msg

� r.

� By de�nition of G, for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = �j :M,

A = (�j :A� f�pg)Sf�contg,

T = �j :TST new ,

P = f"g, where " = hES; � ri (a send event), and

�next is initially unde�ned,

where

[s0]a 7�!act

�cont , since cont(�cont) = s0, [s]a 7�!act

�p , and by de�nition of �cont .

) By de�nition of 7�!cfg

, KAT

i+1 7�!cfg

KdPact

j+1 .

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 1b.

40

Case 1c: actor/message synchronization

� Let KAT

i=DD

Ii ; IEE

�

�

, KAT

i+1 =DD

Ii+1 ; IEE

�

�

, and KAT

i

AT

=) KAT

i+1,

where Ii = f[s]a; a / Mg and Ii+1 = f[s]a; [s0]ag,

s.t. ready?([s]a) is trueV

busy?([s0]a) is true.

� By I.H. and 7�!cfg

,

9�p 2 �j :A, s.t. [s]a 7�!act

�p

V9� r 2 �j :T , s.t. a /M 7�!

msg

� r.

� By de�nition ofAT

=), Am([s]a) yields f[s0]ag.

) By de�nition of F�, 9� 2 F�(�p), where

� = h�cont ;Mnew ;Anew ; T new ;Arepl i,

cont(�cont) = s0 (syntactic equality implies semantic equality).

� By de�nition of G, for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = deliver(�j :M; � r),

A = (�j :A� f�pg)Sf�contg,

T = �j :T � f� rg,

P = f"g, where " = hED; � ri (a deliver event), and

�next is initially unde�ned,

where

[s0]a 7�!act

�cont , since cont(�cont) = s0, [s]a 7�!act

�p , and by de�nition of �cont .

) By de�nition of 7�!cfg

, KAT

i+1 7�!cfg

KdPact

j+1 .

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 1c.

41

Case 1d: replacement speci�cation

� Let KAT

i=DD

Ii ; IEE

�

�

, KAT

i+1 =DD

Ii+1 ; IEE

�

�

, and KAT

i

AT

=) KAT

i+1,

where Ii = f[s]ag and Ii+1 = f[s]a; [s0](a); [t]ag.

� By I.H. and 7�!cfg

,

9�p 2 �j :A, s.t. [s]a 7�!act

�p

� By de�nition ofAT

=), Am([s]a) yields f[t]a; [s0](a)g, where t is the replacement behavior

continuation of actor a, and s0 is the continuation of actor a's initial behavior, s, carried

out by an anonymous actor (a).

) By de�nition of F�, 9� 2 F�(�p), where

� = h�cont ;Mnew ;Anew ; T new ;Arepl i,

Arepl = f�rg,

cont(�r ) = t (syntactic equality implies semantic equality),

cont(�cont) = s0 (syntactic equality implies semantic equality).

� By de�nition of G, for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = �j :MSf(a)g,

A = (�j :A� f�pg)Sf�contg

SArepl ,

T = �j :T ,

P = ;, and

�next is initially unde�ned,

where

[s0](a) 7�!act

�cont , since cont(�cont) = s0, and by de�nition of (a); 7�!act

, and �cont

and

[t]a 7�!act

�r since cont(�r) = t, [s]a 7�!act

�p, and by de�nition of �r .

) By de�nition of 7�!cfg

, KAT

i+1 7�!cfg

KdPact

j+1 .

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 1d.

42

Case 2: in

� Let KAT

i=DD

IEE

�

�

, KAT

i+1 =DD

I ; a /MEE

�

�S(acq(M)��)

, and KAT

i

AT

=) KAT

i+1,

where (a 2 �)V

(acq(M)T

InAct(I) � �).

� By I.H. and 7�!cfg

,

9�p 2 �j :A, s.t. actname(�p) = a

� By de�nition ofAT

=), message a / M is added to KAT

i+1's internal con�guration by an

external entity.

) 9� r from the same external entity, s.t. a / M 7�!msg

� r (=) recip(� r) =

actname(�p), by de�nition of 7�!msg

)

� By de�nition of G and F bin , for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = �j :M,

A = �j :A,

T = �j :TSf� rg,

P = f"g, where " = hES; � ri (a send event), and

�next is initially unde�ned,

) KAT

i+1 7�!cfg

KdPact

j+1 , since by de�nition of 7�!cfg

, I.H., andAT

=), only a / M is

added to KAT

i's internal con�guration, and a / M 7�!

msg

� r. Conditions for actors and

receptionists in 7�!cfg

are unchanged. (acq(M) � �) adds at most external actor names

to �, thus preserving the condition for external actors.

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 2.

43

Case 3: out

� Let KAT

i=DD

I ; a /MEE

�

�

, KAT

i+1 =DD

IEE

�S(acq(M)��)

�

, and KAT

i

AT

=) KAT

i+1,

where a =2 InAct(I)

� By I.H. and 7�!cfg

,

9� r 2 �j :T , s.t. (a /M 7�!msg

� r)V(recip(� r) =2 �j :M).

� By de�nition ofAT

=), message a / M is removed from internal con�guration of KAT

i+1.

� By de�nition of G and Fdout , for n = 1,

9�j+1 s.t. �j+1 = hM;A; T ;P; �nexti where

M = �j :M,

A = �j :A,

T = �j :T � f� rg,

P = ;, and

�next is initially unde�ned,

) KAT

i+1 7�!cfg

KdPact

j+1 , since by I.H., de�nition of 7�!cfg

, andAT

=), only a/M is removed

from KAT

i's internal con�guration, and a / M 7�!

msg

� r. Conditions for actors and

external actor names are unchanged. (acq(M) � �) adds at most internally de�ned

actor names to �, thus preserving the condition for receptionists.

� By de�nition of F�̂(limited transition function), �j :�next = �j+1 is one legal transition.

) KdPact

j

dPact

=) KdPact

j+1 .

� ) Proved I.S. for case 3.

44

Case 4: idle

� Let KAT

i=DD

IEE

�

�

, KAT

i+1 =DD

IEE

�

�

, and KAT

i

AT

=) KAT

i+1,

) KAT

i= KAT

i+1

� By I.H.,

KAT

i7�!cfg

KdPact

j, and since KAT

i= KAT

i+1,

) KAT

i+1 7�!cfg

KdPact

j.

� By de�nition ofAT

=), after zero transitions (n = 0),

) KdPact

j

dPact

=)0 KdPact

j.

� ) Proved I.S. for case 4.

45

Proof: ((=)

8i � 0:9j � 0: KdPact

0

dPact

=)i KdPact

i

=) KAT

0

AT

=)j KAT

j

VKdPact

i7�!cfg

KAT

j:

By induction on i, where i is the height of tree with root �0 .

Base: (i = 0)

i = 0 =) KdPact

i= K

dPact

0 :

So, it su�ces to prove 9j � 0 s.t. KAT

0

AT

=)j KAT

j

VKdPact

0 7�!cfg

KAT

j.

But KdPact

0 = �0 , its root, the initial con�guration of pgm in dPact .

=) �0 = hM; A; T ; P; �nexti, where �0 contains one actor machine, �p , whose

continuation corresponds to pgm, initially denoted s; and no tasks. Thus,

M = fag,

A = f�pg, where (actname(�p) = a)V

(cont(�p) = s),

T = ;,

P = ;, and

�next is initially unde�ned.

KAT

0 is the initial con�guration of pgm in AT big .

=) KAT

0 =DD

IEE�

�

, where I contains one actor, [s]a and no messages. Thus I = f[s]ag,

� = fag, and � = ;.

By de�nition of 7�!cfg

, KdPact

0 7�!cfg

KAT

0 , since

�p 7�!act

[s]a,

message correspondence is true vacuously,

the condition for receptionists is true, since a 2 � and actname(�p) = a, and

the condition for external actors is true, vacuously.

) Base case holds with j = 0.

46

I.H.: Assume for tree �0 of height i � 0,

F i

�̂(K

dPact

0 ) = KdPact

iimplies 9j � 0, s.t.

KAT

0

AT

=)j KAT

j

VKdPact

i7�!cfg

KAT

j.

I.S.: Prove true for tree �0 of height i+1:

That is, prove F i+1

�̂(K

dPact

0 ) = KdPact

i+1 implies

9k � 0, s.t. KAT

0

AT

=)k KAT

k

VKdPact

i+1 7�!cfg

KAT

k.

By de�nition of F�̂, F i+1

�̂(K

dPact

0 ) = F�̂(F i

�̂(K

dPact

0 )).

By I.H., F i

�̂(K

dPact

0 ) = KdPact

iimplies

9j s.t. KAT

0

AT

=)j KAT

j

VKdPact

i7�!cfg

KAT

j.

Consider cases for F�̂(K

dPact

i) = K

dPact

i+1 .

Prove 9n � 0, where k = j + n, s.t.

KAT

j

AT

=)n KAT

j+n

VKdPact

i+1 7�!cfg

KAT

j+n.

Let KdPact

i= hM; A; T ; P; �nexti.

47

Case 1a: create actor

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of create actor:

9b 2 M0s.t. b =2 M,

9�r 2 A0s.t. �r =2 A

Vactname(�r) = b,

9�0p2 A

0, �p 2 A s.t. actname(�0

p) = a

Vactname(�p) = a

Vcont(�p) 6= cont(�0

p),

s.t. M0=M

Sfbg,

A0= (A� f�pg)

Sf�0

p; �rg,

T0= T , and

P0= ;.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE��

,

9[s]a 2 Ij s.t. �p 7�!act

[s]a

) By de�nition of 7�!act

, cont(�p) = s.

� By de�nition of F�, F�(�p) = � = h�cont ;Mnew ;Anew ; T new ;Arepl i,

where Mnew = fbg; Anew = f�rg.

) By de�nition of F� and F�̂, �cont = �0

p.

� By de�nition of Am, Am([s]a) yields f[s0]a; [t]bg, where s

0 = cont(�0p) and t = cont(�r).

Let Ij+1 = IjSf[s0]a; [t]bg.

) By de�nition of 7�!act

, �0p7�!act

[s0]a and �r 7�!act

[t]b.

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE��

.

� By de�nition of 7�!cfg

,

) KdPact

i+1 7�!cfg

KAT

j+1.

� Proved I.S. for case 1a.

48

Case 1b: create task

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of create task:

9b 2 M0s.t. b =2 M,

9� r 2 T0s.t. � r =2 T ; and

9�0p2 A

0, �p 2 A s.t. actname(�0

p) = a

Vactname(�p) = a

Vcont(�p) 6= cont(�0

p),

s.t. M0=M,

A0= (A� f�pg)

Sf�0

pg,

T0= T

Sf� rg, and

P0= f"g, where " = hES; � ri.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE��

,

9[s]a 2 Ij s.t. �p 7�!act

[s]a

) By de�nition of 7�!act

, cont(�p) = s.

� By de�nition of F�, F�(�p) = � = h�cont ;Mnew ;Anew ; T new ;Arepl i,

where T new = f� rg.

) By de�nition of F� and F�̂, �cont = �0

p.

� By de�nition of Am, Am([s]a) yields f[s0]a; b / Mg,

where s0 = cont(�0p)V

b = recip(� r)V

M = content(� r).

Let Ij+1 = IjSf[s0]a; b / Mg.

) By de�nition of 7�!act

, �0p7�!act

[s0]a; by de�nition of 7�!msg

, � r 7�!msg

b / M .

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE��

.

� By de�nition of 7�!cfg

,

) KdPact

i+1 7�!cfg

KAT

j+1.

� Proved I.S. for case 1b.

49

Case 1c: deliver task

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of deliver task:

9� r 2 T s.t. � r =2 T0;

and 9a 2 M0s.t. recip(� r) = a,

and 9�p 2 A0, �p 2 A s.t. actname(�p) = a

Vdel?(M

0; �p) True

Vund?(M; �p) True,

s.t. M0= deliver(M; � r),

A0= A,

T0= T � f� rg, and

P0= f"g, where " = hED; � ri.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE�

�

,

9[s]a 2 Ij s.t. �p 7�!act

[s]aV

9a / M 2 Ij s.t. � r 7�!msg

a / M .

) By de�nition of 7�!act

, cont(�p) = s (syntactic equality implies semantic equality)

and by de�nition of 7�!msg

, content(� r) = M (syntactic equality implies semantic

equality)

� By de�nition of actor/message synchronization,

Let Ij+1 = (Ij �fa /Mg)Sf[s0]ag, where Am([s]a) yields f[s

0]ag, s.t. ready?([s]a) TrueVbusy?([s0]a) True

) By de�nition of 7�!act

, for �i+1 , �p 7�!act

[s0]a

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE��

.

� By de�nition of 7�!cfg

,

) KdPact

i+1 7�!cfg

KAT

j+1.

� Proved I.S. for case 1c.

50

Case 1d: consume task

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of consume task:

9�0p2 A

0, �p 2 A s.t.

actname(�0p) = a

Vactname(�p) = a

Vcons?(M

0; �0

p) True

Vdel?(M; �p) True,

s.t. M0=M,

A0= (A� f�pg

Sf�0

pg,

T0= T , and

P0= ;.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE��

,

9[s]a 2 Ij s.t. �p 7�!act

[s]a.

) By de�nition of 7�!act

, cont(retrieveMsg(�p ;M)) = s (syntactic equality implies

semantic equality)

� By de�nition of F�, F�(�p) = � = h�cont ;Mnew ;Anew ; T new ;Arepl i,

) By de�nition of F� and F�̂, �cont = �0

p.

� By de�nition of actor/message synchronization,

) By de�nition of 7�!act

, �0p7�!act

[s]a

� By de�nition ofAT

=), for n = 0,

) KAT

j

AT

=)0 KAT

j.

� By de�nition of 7�!cfg

,

) KdPact

i+1 7�!cfg

KAT

j.

� Proved I.S. for case 1d.

51

Case 1e: replacement speci�cation

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of replacement speci�cation:

9�r 2 A0s.t. �r =2 A,

9�0p2 A

0, �p 2 A, and

actname(�r) = aV

actname(�0p) = a

Vactname(�p) = a

Vcont(�r ) 6= cont(�0

p)V

cont(�r) 6= cont(�p)V

cont(�0p) 6= cont(�p),

s.t. M0=M,

A0= (A� f�pg)

Sf�0

p; �rg,

T0= T , and

P0= ;.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE��

,

9[s]a 2 Ij s.t. �p 7�!act

[s]a

) By de�nition of 7�!act

, cont(�p) = s.

� By de�nition of F�, F�(�p) = � = h�cont ;Mnew ;Anew ; T new ;Arepl i.

) By de�nition of F� and F�̂, �cont = �0

p, and Arepl = f�rg.

� By de�nition of Am, Am([s]a) yields f[s0](a); [t]ag,

where s0 = cont(�0p) and t = cont(�r).

Let Ij+1 = IjSf[s0](a); [t]ag.

) By de�nition of 7�!act

, �0p7�!act

[s0](a) and �r 7�!act

[t]a.

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE��

.

� By de�nition of 7�!cfg

,

) KdPact

i+1 7�!cfg

KAT

j+1.

� Proved I.S. for case 1e.

52

Case 2: incoming external task

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of incoming external task:

9� r 2 T0s.t. � r =2 T ;V

recip(� r) = aV

content(� r) =MV9�p 2 A, �p 2 A

0s.t. actname(�p) = a,

s.t. M0=M,

A0= A,

T0= T

Sf� rg, and

P0= f"g, where " = hES; � ri.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE��

,

9[s]a 2 Ij s.t. �p 7�!act

[s]a

) By de�nition of 7�!act

, cont(�p) = s.

� By de�nition of F bin , F�̂,

task � r is added to KdPact

i+1 by an external entity.

) 9a / M from the same external entity, s.t. � r 7�!msg

a / M .

� Let Ij+1 = IjSfa / Mg, and let �0 = �

S(acq(M)� �).

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE��0

.

� By de�nition of 7�!cfg

, and I.H.

) KdPact

i+1 7�!cfg

KAT

j+1, since only � r is added to KdPact

i+1 , and a / M 7�!msg

� r.

Conditions for actors and receptionists in 7�!cfg

are unchanged, and (acq(M)� �)

adds only external actor names to �, thus preserving the condition for

external actors.

� Proved I.S. for case 2.

53

Case 3: outgoing external task

� Let KdPact

i+1 = �i+1 s.t. �next = �i+1 and �i+1 = hM0; A0; T 0; P 0; �next0i,

where �0next

is initially unde�ned, and by de�nition of outgoing external task:

9� r 2 T s.t. � r =2 T0;V

recip(� r) = aV

content(� r) =MV8�p 2 A, �p 2 A

0: actname(�p) 6= a,

s.t. M0=M,

A0= A,

T0= T � f� rg, and

P0= ;.

� By I.H. and 7�!cfg

, for KAT

j=DD

Ij

EE�

�

,

9a / M 2 Ij s.t. a / M 7�!msg

� r.

� By de�nition of Fdout , F�̂,

task � r is removed from KdPact

i+1 .

� Let Ij+1 = Ij � fa / Mg, and let �0 = �S(acq(M)� �).

� By de�nition ofAT

=), for n = 1,

9KAT

j+1 s.t. KAT

j

AT

=)1 KAT

j+1, where KAT

j+1 =DD

Ij+1

EE�0

�

.

� By de�nition of 7�!cfg

, and I.H.

) KdPact

i+1 7�!cfg

KAT

j+1, since only � r is removed from KdPact

i+1 , and a / M 7�!msg

� r.

Conditions for actors and external actor names in 7�!cfg

are unchanged, and

(acq(M)� �) adds only internally de�ned actor names to �, thus preserving

the condition for receptionists.

� Proved I.S. for case 3.

54

Appendix C

Scheme Implementation of SECD

Machine

This appendix contains my Scheme implementation of the SECD machine.

; *

; * add1: A "predefined function" which does what it says...

; *

(define add1

(lambda (n) (+ n 1)))

; *

; * app?: Boolean test which returns true when e an "application" of form

; * ('app e e)

; *

(define app?

(lambda (e)

(eq? (car e) 'app)))

; *

; * closure?: Boolean test which returns true when e is a "closure" of form

; * ('closure v b e)

; *

(define closure?

(lambda (e)

(eq? (car e) 'closure)))

55

; *

; * const?: Boolean test which returns true when e is a "const" of form

; * ('const n)

; *

(define const?

(lambda (e)

(eq? (car e) 'const)))

; *

; * func?: Boolean test which returns true when e is a "predefined function"

; * of form ('func n), where n is the name of the function

; *

(define func?

(lambda (e)

(eq? (car e) 'func)))

; *

; * ident?: Boolean test which returns true when e is an "identifier" of

; * form ('ident x)

; *

(define ident?

(lambda (e)

(eq? (car e) 'ident)))

; *

; * lambda-ab?: Boolean test which returns true when e is a "lambda

; * abstraction" of form ('lambda x e)

; *

(define lambda-ab?

(lambda (e)

(eq? (car e) 'lambda)))

; *

; * eval?: Boolean test which returns true when e is a the "eval" symbol

; * (@) of form ('eval)

; *

(define eval?

56

(lambda (e)

(eq? (car e) 'eval)))

; *

; * eval: Function which associates the symbol f with a predefined function

; * of the same name, then returns the result of applying a to f.

; *

(define eval

(lambda (f a)

(if (eq? f 'add1)

(add1 a)

(display (cons f (cons a '()))))))

;'error)))

; *

; * mk-empty: Returns an empty list

; *

(define mk-empty

(lambda () '()))

; *

; * lookup: Checks environment env for variable name, and if found

; * returns its bound value

; *

(define lookup

(lambda (env name)

(cond

((null? env) 'error)

((eq? name (caar env)) (cadar env))

(#t (lookup (cdr env) name)))))

; *

; * update-env: Adds the binding of name to val to the environment env

; *

(define update-env

(lambda (env name val)

(cons (list name val) env)))

57

; *

; * transform: Transition function for the SECD machine

; *

(define transform

(lambda (s e c d)

(cond

; Case 7: if C = []

; -- Must be first. If c is null, can't check anything else!

((null? c)

; If d is also empty stack, then finished, return top of stack s

(if (null? d) (car s)

; else continue by popping saved environment from dump stack d,

; and pushing result currently on s on top of restored s

(transform (cons (car s) (caar d)) ; -the new s

(cadar d) (caddar d) (cadddar d))))

; Case 0: if head(C) is a func

((func? (car c))

(transform (cons (car c) s) e (cdr c) d))

; Case 1: if head(C) is a constant

((const? (car c))

(transform (cons (cadar c) s) e (cdr c) d))

; Case 2: if head(C) is a variable

((ident? (car c))

(transform (cons (lookup e (cadar c)) s) e (cdr c) d))

; Case 3: if head(C) is an application (Rator Rand)

((app? (car c))

(transform s e

(cons (cadar c) (cons (caddar c)

(cons (cons 'eval '()) (cdr c)))) d))

; Case 4: if head(C) is a lambda abstraction lambda(V).B

((lambda-ab? (car c))

(transform

(cons (cons 'closure

(cons (cadar c) (cons (caddar c) (cons e '())))) s)

58

e (cdr c) d))

; Case 5: if head(C) = @ and head(tail(S)) is a predef. function f

((and (eval? (car c)) (func? (cadr s)))

(transform (cons (eval (cadadr s) (car s)) (cddr s))

e (cdr c) d))

; Case 6: if head(C) = @ and head(tail(S)) = closure(V,B,E1)

((and (eval? (car c)) (closure? (cadr s)))

(transform

(mk-empty)

; which is the new s - empty

(cons (cons (cadadr s) (cons (car s) (mk-empty)))

(cadddadr s))

; which is the new e, with V-->B added to E1 from closure

(cons (caddadr s) (mk-empty))

; which is the new c - initialized to B from closure

(cons

(cons (cddr s) (cons e (cons (cdr c) (cons d

(mk-empty))))) d)))

; which is the new d - this saves the current cfg

; after eval

; close the cond, lambda, and define...

)))

; *

; * caddadr: Apparently I reached a limit?

; *

(define caddadr

(lambda (s)

(car (cdr (cdr (car (cdr s)))))))

; *

; * cadddadr: Apparently I reached a limit?

; *

(define cadddadr

(lambda (s)

(car (cdr (cdr (cdr (car (cdr s))))))))

59

; *

; * cadddar: Apparently I reached a limit?

; *

(define cadddar

(lambda (s)

(car (cdr (cdr (cdr (car s)))))))

The following are three test functions for the SECD transform function.

(define test1

(lambda ()

(transform '() '() '((app (func add1) (const 6))) '())))

(define test2

(lambda ()

(transform '() '() '((app (lambda x (app (func add1) (ident x)))

(const 6))) '())))

(define test3

(lambda ()

(transform '() '() '((app (lambda x (ident x)) (const 42))) '())))

Thus, in the Scheme Read-Eval-Print loop, the following transaction occurs:

1 ]=> (test1)

;Value: 7

1 ]=> (test2)

;Value: 7

1 ]=> (test3)

;Value: 42

60