DPL-82: A LANGUAGE FOR DISTRIBUTED PROCESSING

2-Abstract DPL-82 is a language for composing programs of concurrently-executing processes. Processes may be all on a single machine or may be distributed over a set of processors connected to a network. The semantics of the language is derived from the underlying interprocess communication facility (IPC) and from the dataflow model of computation. This paper discusses the major concepts of the language, namely nodes, arcs, connections, tokens, signals, and activations, and presents examples which illustrate the construction of distributed programs in DPL-82 with internal arcs, external arcs and child arcs. Features for process-to-processor mapping and dead process restart are mentioned. The paper concludes with some ideas for future research.


INTRODUCTION
The intention of the research leading to DPL-82 was to implement a programming language to control a local network of computers as if they were a single computing engine. There are many schools of thought with respect to the choice of an underlying mechanism for control and communication in a distributed program.
One important decision is whether the flow of control or the flow of data is emphasized. The control-flow end of the spectrum is characterized in the remote procedure call concept. 1 Somewhere in the middle of the control/data-emphasis spectrum is the MIT Actor model of computation, 2 whose underlying metaphor is the notation of continuation. Current Actor language implementation research is embodied in Lieberman's language ACTI, 3,4 and research is also being done by Clinger on the denotational semantics of Actors, which includes an Actor language called ATOLIA. 5 The data-flow end of the spectrum is characterized in the dataflow concept. 6,7 ' 8 An important descriptive method arising from dataflow research is the UCLA SARA Graph Model of behavior. 9 Our language, DPL-82, is a dataflow language. A final, important, distinction is whether control "remains centralized" after the initial stages of execution of the distributed program. This tends to be the case in the majority of approaches cited in this paper; the exception that proves the rule is the worm control program research of Shoch. 10 * DPL-82 derives its emphasis, not from theoretical constructions of language features for parallelism or out of designs for parallel machines, but from research on operating system mechanisms for interprocess communication. DPL-82 depends on the the port and message concepts of Rashid's CMU VAX/UNIX interprocess communication facility (referred to in this paper as the IPC), 11 to implement a interprocess communication path concept called the arc. The arc is very similar to Morrison's data stream linkage mechanism} 1 ' 13 and the window concept of the Honeywell HXDP operating system. 14,15 A language very similar to DPL-82 is Lesser's PCL. 16 There are several veins of distributed processing language research which do not fall directly into the classifications given above. One is that of languages written for specific hardware architectures, such as Danncnbcrg's AMPL for the CMU CM* processor 17 and Snodgrass's object-oriented language COLA for the CMU C.MMP processor. ITicre is much work centered around the ideas of tasking and semaphores, such as the ADA tasking facility, 19 STAROS Task Force 20 and CLU guardians? 1 Finally we must mention Hoare's very popular CSP language. CSP has a process concept and a compact notation for linking the inputs and outputs of processes, but unlike most of the work arising out of the experimental systems-building community, emphasizes processes which are very small computationally, and binds processes very tightly to each other (each process description is written for exactly one named caller, hence there is no possibility for "libraries" of •Unfortunately that research, which was an experimental exercise in distributed system building, has not, to our knowledge, been abstracted into a set of high-level "worm control structures" that could be compactly integrated into a language. processes which could be "linked" together to form a distributed program).
In DPL-82 a distributed program is composed of processes executing on a number (possibly one) of machines. Each machine in the network supplies some number of processes. A process is a running core image, and each computer might store on secondary memory executable core images for some subset of the different kinds of processes which compose the entire program. The processes are connected with communication channels supplied by the IPC* To make a DPL-82 distributed program or sub-program, user supplied PASCAL code is embedded in a process description which defines the communications interface (input and output communication paths) for the process being described, subprocess requirements, and interconnection of communication paths of subprocess. This description is translated into a complete PASCAL program for that process which may then be compiled and executed in the DPL-82 runtime environment. The runtime environment supplies protocols via the IPC for establishing communication paths between subprocesses and (network transparent) passing of data on those paths, and a facility to allow a DPL-82 distributed program component (process) on one machine to request the loading of a process on another machine (which process may in turn cause the loading of additional processes, etc), DPL-82 also provides the ability to pass parameters to subprocesses at subprocess load-time. For example, the size of various portions of a distributed program (in terms of number of processes) may be a runtime-computed function of such parameters.

PARTICULARS OF THE LANGUAGE
The processes that make up a DPL-82 distributed program are called nodes. Nodes are not to be construed as processors in a network, but rather as processes that those processors provide. A node description consists of a number of sections: • The name of the node.
• Declaration of (children nodes): the u s e s section.
• Child startup and initialization parameters: the i n i t i al ize section.
• Arc interconnection: the connect section which contains arc-to-arc pairs marked by arrows (=>).
• Startup-time-only computation: the to_instantiate section, and • activation conditions: the activate section which controls the handling of tokens, signals and child processes thereafter.

Arcs
The communication links between nodes are called arcs. Arcs are implemented with IPC ports.* A node, through its DPL-82 description, may declare a variety of input and output arcs. Arcs transmit tokens and signals. A token, modelled after the concept of a token in dataflow networks, 6 is a typed data object. A signal is a string. Tokens and signals are communicated by IPC messages.
There are three sorts of arcs: • An internal arc is a connection between a parent node and a child node. The actual connection is made by the parent. The parent is the process which starts a given (child) process, whether or not the parent process is on the same machine as the child process.
• An external arc is a path into or out of a node, which is declared inside that node, but whose connections are set by the parent of the node.
• A child arc is declared by a child node, and is connected to a sibling of the child by the parent node, but is then subsequently reconnected by the child to one of its children. Tokens or signals subsequently passing along this connection do not go to the child, but go directly to the child's child from the originator of the arc or signal.
These three varieties of input and output arcs provide distributed processing analogues to expressions, subroutines and main programs in uniprocessing languages. A computational process with external arcs is like an expression.** A child process which configures a sub-network of interconnected nodes and associates unconnected arcs of the sub-network with child arcs is like a subroutine. Finally, a node with no external arcs that creates a network of child nodes (and may connect itself to that network with internal arcs) is like a main program.

Starting nodes
The initialize statement loads a process and provides it with parameters. For example: (for i from 1 to 5 (initialize node TrafficLight(i)[i])) starts up five Traff icLights. The first use of i (in parentheses) refers to the particular instance of *A port is like a mailbox, of which a process may own several, to which data may be sent in the form of messages.
••This analogy is fairly apt, given work such as that of Arvind which takes expressions in a functional language and "flattens" them into dataflow networks. 5 is with respect to the parent A child node does * We are passing it because we want each TrafficLight to know what its name i not automatically know it's "name" in DPL-82. **Oann£nbcrg discusses a design for a more general network operating system mechanism called the BUTLER for remotely allocating processes. ***Thc ability of connections to survive process death is a property of the IPC mechanism.
Traf f i cLi ght being loaded. The second use (in brackets) is a integer-valued parameter being passed to that TrafficLight instance.* One can start a process on another machine with a statement like: (initialize node Correlator on_host "CAD-VAX") which says to load a process whose core image is stored on file name Correlator on the processor whose symbolic local net address is "CAD-VAX".**

Connecting nodes
The => statement makes connections between nodes. For example: connects philosopher number four's hand to fork number five's handle.

Activation conditions
The remainder of the node description is taken up by the activation conditions, which allow tokens and signals to be received and transmitted, and other actions to be taken such as node self-termination and child node restarting. These may be contingent upon signal and token arrival, timeouts, internal state of a user's PASCAL code, and boolean combinations of the above.
The following DPL-82 activation condition-action pair detects the death of a process and restarts it: This is a primitive restarting capability, whose only effect is to start a process of the same name and give it the connections of the dead process***. Nothing in the language deals with the question of restoring the internal state of a lost process.

SOME EXAMPLES
We will now present a number of simple nodes to illustrate the concepts discussed above. It is important to note that these nodes are not very computation-intensive, and that the real economy of this language comes with nodes which do more work. Also, we will not, in this paper, present any timing measurements for establishing connections or passing tokens or signals, and we will not consider the problems of optimal proccss-to-proccssor mapping. This is partly due to space limitations, and partly due to the fact that the primary thrust of this research has been to achieve correct mechanisms in terms of functionality and linguistic expression. Future research, on a successor to DPL-82 (DPL-83?), may be concerned with mechanism optimization and resource allocation issues.*

Nodes with inputs and outputs
The simplest kind of interesting node must communicate with and start other concurrently processing nodes in order to perform a computation. To do this, the node must declare input and output arcs and must include in its description specific commands for starting up other nodes. Let us concieve of a node which performs the x 2 function called xsquared, and another node which utilizes xsquared in a simple parallel computation, which we will call plus2xsq. It will present two xsquared nodes with numbers, and sum and print their results.
The only way that information can flow out of the purview of the internal arc owner and into the purview of the node that starts up the owner, is if the internal arc owner connects a child arc to an internal arc (see below).
We can illustrate the use of child arcs with the node xf ourth, which has one input child arc and one output child arc. xf ou rth outputs the value of the input raised to the fourth power, xf ou rth is shown in   We can exercise xf ourth with the following node, f ourthstream, which reads integers from the terminal and prints out their fourth powers. When the end of the input stream is reached, fourthstream terminates after sending a halt signal to xf ourth. xf ourth will then signal its xsquared subordinates to halt, and terminate itself. The xsquared nodes will terminate themselves, and the distributed computation will conclude.
The definition of xsquared must be modified slightly to catch the signal. We will call the new version newxsquared. newxsquared also does not terminate after the first set of input tokens, but rather cycles indefinitely until the hal t signal has been received

Cyclic checking of activation conditions
The concept of cycling is very important. The default action of the node is to wait for IPC messages which represent tokens or signals, then evaluate the activation conditions, which usually refer to token or signal arrival events. However note that in fourthstream the first activation condition refers to a side-effect generated by the next activation conditions. This side-effect emanates from the input_st ream procedure, and signals that the end of input has been reached. The creation of the side-effect is dependent on the user's typein, and not on message events (although it strictly follows the last resul t token arrival). Hence the detection of the side-effect docs not involve waiting for a message event. If we chose the default action of waiting forever for a message event, then the first activation condition would never be tested.
The solution chosen here is to modify the amount of time we arc willing to wait for message events. This time is chosen so that we don't needlessly check the activation conditions while actually waiting for messages, SOME EXAMPLES PA GII9 and so that we don't wait too long, when we aren't expecting messages, to get around to checking the non-mcssagc-evcnt-rclated activation conditions. When the user is typing in numbers, fourthstream might catch a "timeout" or two before receiving the response, but this is harmless. When the user types in the number -1, indicating end-of-input, the variable EOS is changed to true. The node will wait at most 500 milliseconds, when EOS condition is true, to signal "end of computation" and terminate.* We have now use, child, and in^a! arcs. ,"r«.tr.-T. -ne-wo* * pictured ,

FUTURE RESEARCH
We intend to implement abstractions of the features of this language in Edinburgh ML, 29 an interpreted, typed functional language designed for research in denotational semantics, 30 as a first step toward the development of a power-domain based 31 semantics of the underlying IPC facility and the conceptual features of the language.
There are some intriguing possibilities for the design of a microprocessor or microcoding of a processor whose instruction set is optimized towards message-passing and distributed programs whose underlying control construct is the continuation. The notion of a continuation is to be found in Actor semantics, 2 the notion of the RTRANSFER in remote procedure call, 1 and in denotational semantics. 32 The concept of constraint networks may find a home in the distributed processing context with dataflowlike languages, such as a successor to DPL-82, which are extended to include the notion of bi-directional arcs (now simulatablc with pairs of input and output arcs) and appropriate relaxation procedures. 33,34 1.

ACKNOWLEDGEMENTS
The author is indebted to Prof. Raj Reddy for providing him with funding and research facilities to do this,