Object Oriented Load Distribution in DinnerBell

Here we describe an object-oriented language based on finegrained parallelism. This language, called DinnerBell, is based on single-assignment rule and data driven execution. We use messageJoin as a synchronization mechanism. DinnerBell is implemented using micro-message technique. DinnerBell also uses a new method called object-oriented load distribution. This method works like a macro data flow, however, it works automatically and is much more controllable. The simulation results of this method are also examined. 1 Fine-Grained Parallel Language: DinnerBell DinnerBell [kohda84] is a fine-grained parallel object-oriented programming language. It is designed to achieve high software productivity from its object-oriented feature and high execution performance from its fine-grained parallelism. Several parallel object-oriented languages have been proposed [Yonezawa87, Yokote87, Ishikawa87]. However, they are based on coarse-grained parallelism and their objects are singlethreaded. This reduce parallelism and controllability of objects. As in Fig1, some of them introduced multiple threads in rather ad hoc way, with message priorities and express messages. The concept of dataflow is considered to be effective for introducing fine-grained (and high) parallelism within an object. Dataflow machines have been extensively investigated in the past decade. Hardware prototypes have also been operational (e.g., [Shimada87]). Several programming languages for dataflow machines (e.g., [Ashcroft86]) and fine-grained parallel programming languages (e.g., [Ueda85, Steele87] have also been developed. 0 Object A Object B Object C B/A Thread B/C thread Fig. 1: Multi-threaded Objects Interaction. Some of them employ a combination of dataflow concepts and object-oriented concepts. Such combination has also been tried in some macro dataflow languages [Grimshaw87, Kaiser87]. These languages allow multiple activities within objects. DinnerBell’s approach is unique in that it provides fine-grained execution. The key concepts in DinnerBell are (1) the single-assignment rule which enables parallel execution within an object and (2) messageJoin which creates a consistent state in fine-grained parallel execution. Our language is a pure message-passing based language with synchronization primitive, like [Ward80]. The major modification is the addition of the synchronization mechanism messageJoin. The approach of fine-grained parallelism used in DinnerBell also appeared in [Zhong87] which has Dataflow constructors such as loop. In fine-grained parallel execution, we must achieve low communication overhead. DinnerBell uses a new approach for load distribution in multi-processors namely object-oriented load distribution (hereafter called OO-distribution). This paper examines the simulation results of this method. 1.1 Fine-Grained Parallelism Our approach is to remove unnecessary side-effects. In DinnerBell all variables have single-assignment nature, i.e. they are pure and free of side-effects. A a dataflow graph is constructed dynamically, during execution. In order to express process communication we need some kind of non-determinism or side effects. Necessary side effects are introduced by a non-deterministic technique called messageJoin. Although many languages use guard as a synchronization primitive, our approach is different. The advantage of our approach is that non-determinism is separated from conditional statements. States and side-effects can be implemented by the messageJoin. DinnerBell = single-assignment variable (pure part) + messageJoin (side-effect part) Usually merge or serialization is used in concurrent objectoriented languages [Yoshida88, Agha87], but they restrict objects to be single-threaded. Of course, the pure part is easily executed in fine-grained parallelism. class Add [ inc:X * #1 ret: (X +:1) ] Fig. 2: Simple Program. Fig. 2 shows a simple program written in DinnerBell. The method inc: in class Add increments the argument X and returns the result to the sender of the message. * states for the sender of the message. A square bracket separates the message pattern from the method’s body. ret: Z( Add inc:Y The ret: keyword can be omitted because a syntax sugar that simulates assingment is provided (see Fig.3). But actually, there is no assignment because there is no change of values. Fig. 3 shows the dataflow graph generated by the message passing program of Fig. 2. Since +: is a primitive message, it corresponds to a plus node in the dataflow graph. Y Z [Y+1] Z( Add inc:Y [inc:X *(X +:1)] Control Flow Data Flow Fig. 3: Dataflow Graph. 1.2 Non-Determinism and State Implemented with MessageJoin Here we show a usage of the messageJoin technique. Fig. 4 is a simple program that has state. The class Register has three methods: read! content: accepts read-requests and returns the content, write: content: accepts a write value and changes the content, new: creates an instance of this class with new content. There is no distinction between class methods and instance methods in DinnerBell. The first message sent to a class always causes instance creation. The new: method creates an instance and then sends a message content: to self. The default destination of message passing is self. Message-passing to self, a programming style of Smalltalk, is like a function call within a class. class Register [ new:X content:X read! content:X * #1 ret: X.content:X write:New content:X * #1 ret: X. content:New ] Fig. 4: Register. The second and third methods use the messageJoin mechanism. If both the messages read! (unary message) and content: arrive at the object, the second method read! content: fires. When several corresponding messages are available, one message is selected non-deterministically. For example, if many read! messages and many content: messages arrive at the object, one read! message and one content: message are selected, and these messages fire. In Register, object’s state is represented by method variables. Sending the message content: changes the state of the object. The first method, new:, decides the initial state of the object. Method read! content: returns the current state to the sender of the message read! (the sender of the first message is * #1), and sends the message content: with the same state to self. * #1 and self are both pseudo variables. In DinnerBell, the default destination of a message sending is self, so we can omit the self pseudo variable here. * #1 denotes the sender of the first of joined messages, and * #2 denotes the second. The method write: content: sends a content: message with a new state to self. This causes change of the state. This simple Register object is an example of transaction in DinnerBell. Here is a possible usage of Register. First a register object is created. Then two transaction access the register. Since there are no serial executions in DinnerBell object, the order of two transaction is non-deterministic. Value of the variable X can be 0 or 1. R ( Register new:0. X ( R read!. Y ( R write: (Y +: 1) In Fig. 5, objects first interact by messageJoin, then communicate each other by dataflow and pure message. Object A Object B Object C Join