graphical design of distributed applications through reusable components

Graphical Design of Distributed Applications Through Reusable Components Alberto Bartok, Paolo Corsini, Gianluca Dini, and Cosimo Antonio Prete Universita di Pisa

8 %e Tracsgraphical programming environment promotes a modular approach to the development of distributed applications. A few types of reusa ble design components make the environmen both simple and powerful.

M any programming tools and environments have been developed for parallel and distributed applications. Some of these systems define new -parallel-programming methods, while others provide a framework with- ,in which the developer can choose the most appropri-

ate of several existing methods. Our Tracs programming environment applies the latter strategy to the

development of applications that will be distributed across heterogeneous machines on a local network. Tracs promotes a modular approach that forces programmers to structure their applications cleanly, with well- defined interfaces between the various components. Application design in Tracs consists of two major phases: definition and configuration. In the definition phase, the programmer builds the basic design components: message models, task models, and architecture models. In the configuration phase, the programmer constructs an application from the design components created in the definition phase. Components can be made context-independent, thus promoting their reuse. Tracs also combines its basic absaactions to provide such powerful facilities as the ability to use sequential code, the automatic generation of repetitive task graphs, and the automatic generation of code for message analysis and manipulation.

The overall programming model The programming model that Tracs presents to the programmer is a rather traditional one based on message passing. In this model, at a given

Spring 1995 1063-6552/9S/$4.00 0 1995 IEEE 37

Figure 1. A window for defining message models.

instant a set of applications may be running, each com- prising one or more tasks. The internal structure of each application is static, but applications can be dynamical- ly created and destroyed. Each task has its own address space, and interacts with other tasks primarily via a service, a mechanism similar to a remote procedure call. Tasks belonging to the same application can also interact via a lower-level mechanism - either synchronous or asynchronoGs communication along point-to-point unidirectional channels. A task sees only one channel endpoint, which we call a port . Both ports and services are accessed through library functions; the current prototype supports C, C++, and Fortran.

Each task sees the abstractions for communicating with other tasks through names that are local to the task itself. The programmer specifies bindings between local names during the configuration phase. The environment ensures that changing a binding does not involve recompiling the corresponding tasks. This feature makes it possible to write context-independent tasks (within the limits of use of the environment’s communication primitives) - that is, tasks whose code does not depend on which tasks they interact with nor on which hosts they are placed in. This feature is fundamental in our framework; without it we would have little freedom to mix the basic design components.

Also crucial to the programming model is the message model, which is a template for the structure of a message. Each port is associated with a message model, and mes-

~

38

sages flowing through that port must observe the corresponding model, This constraint is automatically enforced in C++, while in C and in Fortran it is up to the programmer to use a port correctly. Similarly, a service is associated with two message models, one describing the format of the request, the other describing the reply.

Tracs internally maps message models onto the XDR data definition language.’ Therefore, a message model can be made up of fairly com- plex data structures: structures, variant records, variable-length arrays, linked lists, and so on. The programmer does not have to know XDR, however. He or she defines a message model graphically and then, by clicking on a button, sees how to use that

model with the programming language of interest. All these features together simplify the programming of communicating tasks written in different languages.

Furthermore, the programmer-written code never needs to address data heterogeneity. It simply passes a message buffer to the library, which takes care of mar- shaling or unmarshaling the message in a commonly agreed-upon format (XDR) only when necessary. Thus we avoid embedding any configuration-dependent assumptions and unnecessary conversion overhead into the code.

AN EXAMPLE T o explain the various design phases here, we’ll use a simple example that simulates a harbor traffic control system and uses all the Tracs intertask communication abstractions. For convenience, we’Il use only two of the Tracs design components - message models and task models - in the example; we’ll discuss architecture models later.

We define a set of identical and independent tasks, each simulating a ship in motion. All ships periodically communicate their current speed and position to another task, say ship-manager, which in turn forwards the state of the harbor -number of ships, motion parameters - to other tasks devoted to detecting dangerous situations in advance. A task called c o 11-d e t ec t checks the mutual positions and speeds of ships to pre- vent collisions. Two tasks called f ixob j-detect and

IEEE Parallel & Distributed Technology

a r e a-d e t e c t check ship move- ments in relation to fixed objects in the harbor (wharves, beaches, and so on) and areas forbidden to navigation. Whenever they detect a dangerous sit- uation, they notify a task called harb-manager. h a realsystem, this task would alarm the operator to undertake the necessary safety actions; in our example, it simply prints a message to the output window.

Concerning the intertask communication abstractions, ships communi- catewith ship-manager viaservices. The other tasks interact via ports.

Figure 2. Translation of a message model into a programming language.

The definition pbase The definition phase consists of three subphases in which the programmer defines each of the three basic components that will be used to construct applications: the message model, task model, and architecture model. The programmer can carry out these subphases in any order as well as switch back and forth among them. A collection of components of the same kind can be saved as a separate library. The graphic interface provides a specialized window for each basic component.

T o define message models, the programmer has to identify the kinds of messages exchanged in the application. In oui- example, we need two message models: one to describe the motion of a ship, and one to describe dangerous situations. The former, which we call RAD, will be used for communication between ships and ship-manager as well as from ship-manager to the tasks devoted to detecting dangerous situations. The second message model, CTL, will be employed for noti- fylng harb-manage r of dangerous situations.

Figure I shows how message models are defined. The upper part of the window shows three members of the RAD model; moving the sliding bar on the right would reveal the remaining members. A member of a message model may be any of the basic XDR types and con- structors (buttons in the middle) or a user-defined type (listed in the subwindow at left). These types in turn are defined via a similar window, except for the additional possibilities of defining enumerated types and variant records (XDR unions).

As we mentioned earlier, the programming environment internally maps message models onto the XDR data definition language. Once a message model has been

defmed graphically, the programmer can click on a button to see how that model interfaces with the programming language of interest. Figure 2 shows how the RAD message model is translated into C/C++. The p-hd 1 field, needed by the runtime support, is inserted automatically; its content is opaque to the programmer.

The second basic component, the task model, is a complete description of a task, and it may be instantiated to one or more tasks. This description consists of the task interface-that is, ports and services together with relevant local names and message models-and the code. A task model also includes such information as the programming language used and restrictions on the possible allocations of instances of that task model (if they cannot be executed on all the hosts). In our example, the only identical tasks are those that simulate ships. There- fore, we need a single task model for all the ships and a taskmodel for each remaining task: one for ship-man - a ge r, three for the different tasks detecting dangerous situations, and one for harb-manager.

Figure 3 shows a window supporting this definition subphase. In this case, the manager task model being defined will be used for the ship-manager task. The task model exports a service named ship s e r v and has two output ports, shiptx and ob j tx , both associated with message model RAD. A third output port, a re at x , is also being defined and associated with RAD. Ships will invoke ship s e rv to communicate their motion parameters; the output ports will forward each ship’s state to the three tasks devoted to detecting dangerous situations.

In the task model definition window, we can define a port, for instance, by clicking on a button; then we asso-

Spring 1995 39

Figure 3. A window for defining task models.

ciate the port with a message model chosen from a pop- up menu. While we are defining a task model, we can type its code into separate editing windows and split it into several files.

me configuration pbase In the configuration phase, the programmer constructs a complete application from the basic components defined during the definition phase. The programmer can choose these components from user-defined libraries or libfaries supplied with the environment. If the existing libraries fulfill the application’s needs, the programmer can even skip the definition phase, either in part or completely. Configuration involves

1 . defining an application’s logical structure - its con- stituent tasks, their interconnections, and the services exported to or imported from other applications - and

2. defining the placement of tasks on the available machines.

Figure 4 shows a window containing the complete logical structure of our example. The programmer can define a new task by clicking on a button and then associating it with a task model chosen from a pop-up menu. Placement of tasks on available hosts is similar; the programmer clicks on the icon representing a task and then selects a host from a pop-up menu. To define connections between tasks -bindings between local names of ports and services - the programmer draws lines with the mouse, connecting the icons that represent the

respective ports and services. As we will discuss later, it is also possible to use entire clusters of tasks, or architecture models, rather than single tasks as basic design components. In that case, the programmer selects a component from a pop-up menu of architecture models.

Tracs supports more than the design style we have followed here. For instance, we could start by draw- ing in the configuration window a lay- out similar to that in Figure 4 by using only empty tasks and untyped connections. Then, we would refine the design by identifjmg tasks that perform similar actions and connections that carry structurallv identical mes-

sages. Having thus decided on the necessary design components, we would switch to the definition phase to build them. Finally, we would use these components in the configuration phase to fill all the empty items.

Mixed design approaches are possible as well, since Tracs allows the programmer to freely switch back and forth among the various design phases. During the design process, programmers can thus deal either with partially unspecified components or with components that use other components that have not yet been defined. In the former case, for instance, the programmer might define only the communication interface of a task model and defer the coding till later. In the latter case, the programmer might associate ports with message models that have not yet been defined (unlike what we did in the previous section). In other words, when the environment presents a pop-up menu for selecting a message model (Figure 3), the programmer can just add a new entry to the menu. Similarly, in the configuration window, the programmer might associate a task with a task model that does not yet exist. A partially specified application can be saved for later resumption and completion. However, Tracs will not allow the creation of an actual application until every component has been defined.

CREATING AN APPLICATION Whenever the programmer tells Tracs to define a new application starting from the current description, the environment automatically checks that the corresponding design components have been mixed consis- tently. The consistency checks include logical constraints and heterogeneity constraints. Lopal constraints

40 IEEE Parallel & Distributed Technology

have been violated, for instance, in intertask connections that make no sense, such as connections between ports associated with different message models and connections between two input ports. Checlung heterogeneity constraints involves cross-checkmg a systemwide host description and the various task model descriptions, thus preventing, for instance, allocation of an instance of a task model written in Fortran to a machine that does not have a Fortran compiler. Tracs performs every check as soon as possible, so that, for instance, illogical connections are rejected immediately.

Apart from these checks, performed while the programmer attempts to complete the configuration phase, the environment also helps the programmer apply the basic components correctly during the configuration phase. For example, the display uses colors to convey information. Each message model is associated with a color, which fills the icons of all the ports associated with that model. Each connection between tasks is drawn in the color of the message model associated with the

Figure 4. A window for configuring an application.

Y

correspondink endpoints. Each task model is also associated with a color, which fills all the tasks that are instances of that model. Tasks not instantiated yet to any task model are filled with a different specific color. This use of color makes a great deal of information immediately available to the programmer. For instance, in a set of tasks, colors show which connections between ports and services are allowed and which ones are not. For two or more tasks all with the same interface (that is, all associated with the same sets of ports and services), colors show which ones execute the same code and which ones do not. In an intricate graph of an application, colors show which connections carry which lund of messages.

When the programmer has successfully defined a new application, the environment generates a makefile containing all the rules for constructing the necessary executables. Because they embody knowledge of the architecture of the machines composing the system, the rules support remote compilations transparently and effi- ciently. If several instances of a given task model must run on machines that adopt the same executable format,

only one compilation is made. Tracs makes remote copies of files only when there are accessing machines that do not share the file system with the programmer's machine. The environment also generates a group of shell scripts for starting and killing the whole distributed application, for associating each task with a separate window, and for attaching the standard input, output, and error of each task to files (which are also transparently copied back and forth, if necessary).

Architecture models The third basic component supported by Tracs is the architecture model. Architecture models support descriptions of parallel programs - complete or not - that do not depend on what the single tasks actually do,2 thus simplifylng and speeding up application development. The environment provides some powerful graphic operations that greatly simplify the construction of architectures that include repetitive substructures, such as trees and arrays.

.- I--- ' Spring 1995 41

~~~~~

Figure 5. A window for designing architecture models. In designing an architecture model, the programmer performs actions similar to those allowed in the configuration window, such as creating new tasks and defining interconnections.

An architecture model is a logical description of a cluster of tasks, similar to a complete application. How- ever, an architecture model is substantially different from an application. For one thing, in an architecture model, one or more ports or services may be left unbound. Also, an architecture model is described in terms of formal message models and formal task models. Afomzai message model is a message model that has only a name, without any structure. A f m a i task model is a task model specified only in its interface; no code is associated with it. Furthermore, the message models associated with its ports and services are formal ones.

T o use an atchitecture model as part of an application, the programmer must instantiate all the formal task models to actual task models, which specify both the code executed by the task and the structure of the corresponding message models. The environment then checks to see that the instantiation makes sense - that the interfaces of the formal and the actual task models are compatible.

Suppose tha t the programmer wants to define an architecture model describing a task farm. This involves defining two formal task models: one for the master and one for the workers. The interface of the former, m, is composed of an exported service, s. The other formal task model, w, imports service s. Formal task models are defined through a window similar to the one for defining actual task models (Figure 3). Having defined the formal task models, the programmer defines a task farm by creating one instance of m and many instances of w and interconnecting them properly (Figure 5). Finally, the architecture model so defined is saved for later use.

Now, suppose that during the configuration phase,

the programmer wants to build an actual task farm using the building block just defined. Just as with the other basic components, the programmer clicks on a button and selects the desired item from a pop-up menu. The peculiarity of architecture models, however, is that all the formal task models must be instantiated to actual task models, since they have no code and their message models have no structure. In our example, the programmer must use the mouse to instantiate all instances of both m and w to actual task models: he or she selects a set of task instances of the same formal model and then picks the

desired task model from a list (Figure 6a). After all instantiations have been performed, the

architecture model becomes a set of tasks and interconnections in the configuration window (Figure 6b), allowing the programmer to perform usual operations such as adding new tasks and changing interconnections if necessary. An architecture model can thus serve as either a complete application or just a starting point for further design actions.

In this example, the actual task model tor m behaves as the master of a task farm; that is, it partitions the prob- lem to be solved into many independent jobs. Similar- ly, the actual task model for w behaves as the worker of a task farm; it executes a loop in which it invokes service s for returning the result of the previous job and getting a new one, and then carries out the new job. By properly specializing the various formal design components, we could use the example architecture model in different scenarios - for instance, in applications with a client-server structure. We could even use it to build part of the application in the harbor control system example discussed earlier.

%PE"D% SUBSTRUCTURES Tracs offers a powerful feature for handling architecture models made up of repetitive substructures. It provides graphic facilities that let the programmer replicate a basic "tile," quickly and easily creating a task graph in which the connections between the borders of adja- cent tiles are all the same. These repetitive task graphs include most of the useful structures: farm, ring, array, grid, torus, tree, and so on.

If we want to create a task graph while defining an


architecture model, we use the mouse to select the tile we want to replicate. Then we click on a button to enter replication mode, and a replication window containing the selected tile appears on the screen. We perform some operations with the mouse and finally click on a button to replicate the tile as many times as needed. Tracs places the result of this process back into the window that describes the architecture model being defined.

Two features make the replication process powerful:

Tracs automatically defines all the connections between tiles. The replication process can grow exponentially, depending on the tile structure.

Suppose we want to define an architecture model describing an array of identical tasks. T o generate such a graph automatically, we can use the basic tile shown in Figure 7a, where both ports are associated with the same formal message model. More precisely, we create such a tile in the architecture window, select it with the mode, and then enter the replication mode. Next, to enable the environment to automatically define the connections between the newly created tiles, we specify which border of a new tile must be connected to which border of an old tile. In our example, these borders - that is, sets of ports - are, respectively, the input port and the output port of the task composing the tile.

Figure 7b shows the result after three iterations. Tracs defines the connections automatically. If the (formal) message models associated with the input ports had differed from those associated with the output ports, the environment would have rejected the attempt to replicate the tile.

Now consider the more general case in which the borders of both the

Figure 6. The first window (a) shows a snapshot of the instantiation of formal task models to actual task models. A set of (previously selected) instances of the formal model w is being instantiated to the actual task model cruncher. Tracs will check that cruncher has the same interface as w (one imported service). The second window (b) shows the configuration window after all necessary instantiations. The environment automatically instantiated formal service s to the actual service task -bag as a side effect of the instantiation of w to cruncher. Note that if dispatcher had not exported task-bag, the environment would not have allowed the instantiation of m to dispatcher.

Spring 1995 43

Figure 7. Two windows of the architecture replication procedure. The first (a) shows a basic tile, just imported from the window for defining architecture models, while the second (b) shows the same tile replicated three times. The programmer has selected the border of the old tile as the output port and the border of a new tile as the input port. This is done in the replication window (a), where the three buttons on the lower part of the sidebar select the border of the old tile, the border of the new tile, and the part of the tile that does not belong to any border.

old and new tiles contain many ports or services. How should the environment assign the connections? Includ- ing message models in the basic design components enables the environment to collect substantial information from the ports and services composing the borders. For instance, an input port can be connected only to an output port of the same message model. Therefore, difficulties can arise only if this information is insuf- ficient to resolve the assignment conflicts - for example, if there are m input ports in the border of the old tile, there are n output ports in the border of the new tile (m, n 2 I), and all these ports are associated with the same message model.

To cope with such cases automatically, we have chosen a rule that, although not general, describes exact- ly what the programmer wants in practice: The set of ports and services composing a border is ordered according to the position of the corresponding icon on the display. When their: is an assignment conflict, Tracs resolves it by choosing the assignment satisfying this order, if such an assignment exists (Figure 8). It might be useful to allow the expert programmer to change such an assignment, but in most cases this is not necessary.

T o understand Tracs’s exponential- growth feature, consider the case of an architecture model structured as a tree in which each node has one father and three children. The programmer can obtain this architecture model by replicating the basic tile shown in Fig- ure 9a, where the border of an old tile is the set of the three output ports, and the border of a new tile is the input port. Tracs can figure out that to sat- isfy these border constraints, it must attach three new tiles to each old one. Therefore, it will create three new tiles at the first iteration, nine at the second (shown in Figure 9b), 27 at the


third, and so on. Tracs does every- thing almost without intervention from the programmer, who con- tributes just a few mouse clicks and can undo the replication if it does not pro- ceed as expected.

Advanced features Tracs’s modular approach has allowed us to enrich the environment with several facilities that fit nicely in the overall framework. These include the ability to automatically generate implementation details of certain design components and to automatically generate complete design components that are useful during application development.

USING SEQUENTIAL CODE The programming environment simplifies the creation of certain design components by automatically gener- ating certain implementation details. Specifically, it allows the programmer to define task models in which the programmer-written code is fully sequential - that is, code that does not invoke any mebsage-passing construct. The programmer has only to choose a desired task-interaction style, which we call a behavior, from a set of predefined alternatives. For instance, to define a task model with a filter behavior, the programmer simply

I. defines a task model with one or more input ports and one output port;

2. types that model’s code as a sequential subroutine, which will have one output argument and as many input arguments as input ports; and

3. clicks on a button to choose a predefined behavior, and chooses the item labeled “filter.”

The programmer-supplied subroutine is automatically invoked whenever

Figure 8. An example of architecture replication showing the rule for resolving assignment conflicts. (a) A basic tile. (b) The architecture model obtained with two replications. For simplicity, all ports are associated with the same message model (whose name is not shown). The old tile’s border has been selected as the output port set left unbound; the new tile’s border is the input port set left unbound. Clearly, the output port of the task at the upper left corner of (b) might have been connected to any of the newly created tile’s input ports. Tracs, however, orders the ports composing the tile borders according to their display position, and then it resolves the assignment conflicts by using that order.

___________- Spring 1995 45

Figure 9. An example of exponential growth of the replication process: (a) A basic tile just imported from the architecture window, and (b) the architecture model obtained with two iterations. The border of the old tile has been selected as the set of the three output ports; the border of the new tile as the input port.

there is a message on each input port, and the result from the subroutine is (asynchronously) sent through the output port. A dialog box handles the matching of the subroutine arguments and the port names. The environment, starting from the desired behavior and from the task model’s interface, generates a code that wraps around the programmer-provided code to perform synchronization and intertask communication.

Other predefined behaviors include master and worker (for supporting task farms), generic server, ring element, pipeline element, and grid element (for supporting data-parallel computa- tions). T o use any of them, the programmer must know only a generic description of the corresponding behavior. For instance, the worker behavior is described as follows: The interface of a worker is made up of one imported service, say S. The code executes the following loop:

1. Call service S to send back the result of the previous job and get a new one (the first iteration automatically constructs a null result, which means “I’ve just started.”).

2. Execute the received job.

The loop is exited and the task termi- nated when a null job is received in step 1. The programmer must provide only a sequential subroutine for performing step 2. Note that we can build the task models cruncher and d i s p a t c h - er in Figure 6 by this technique, by associating them with the worker and master behavior, respectively.

The possibility of delegating to the environment the duty of managing intertask communication, in conjunc- tion with the possibility of writing task codes in C, C++, and Fortran, is a powerful means of reusing existing sequential software. This feature speeds up and simplifies the development of distributed applications, since


Related work Tracs is one of several graphical development systems that try to provide a level of abstraction higher than that provided by libraries such as PVM3.I Tracs is similar to Conic2 in the emphasis placed on the context-inde- pendence of the design components.

Tracs is most similar to parse^,^ which is based on a skeleton-template- module approach. Parsec focuses on reusability and on finding a proper match between programs and computer architectures. I t achieves these goals by letting the programmer select from a set of parameterized process graphs (parallel-programming paradigms such as farms, trees, and so on). T h e programmer must specify the required parameters.

Tracs takes a similar, component- based approach to the building of context-independent design components, but it strives for a different trade-off between flexibility, generality, and ease of use. Whereas Parsec uses specialized windows for the various parallel- programming paradigms, Tracs uses a design component called an arcbitec- t w e model to treat all the paradigms uniformly. Tracs also provides a fully graphical procedure that enables the programmer to build new architecture models quickly, if they were not available in the basic set. Our system emphasizes graphical interaction not only for choosing and connecting components but also for the development of the components themselves. Moreover, the message type attains the

status of a basic design component, greatly enhancing the system’s modularity and making the interface between the other design components more explicit. On the other hand, we do not particularly address the prob- lem of mapping the application on the underlying architecture. A similar comparison can be made between Tracs and Code/ROPE,‘J another environment that emphasizes application structuring with basic design components and component reuse.

Enterprise6 is also similar to Tracs. It supports a fixed number of parallel- programming paradigms (called assets in the system’s enterprise-based ter- minology). T h e programmer simply specifies the required asset and types the sequential code, and Enterprise generates the code needed for communication, synchronization, and so on. Although Tracs provides similar capabilities for certain frequently used process-interaction patterns, we did not attempt to define novel parallel- programming paradigms. Our intend- ed users do not mind dealing with processes, channels, and messages. They want a tool that promotes the use of a proper design methodology, to reduce the probability of errors and increase reusability and modularity.

Hence7 simplifies the job of a programmer unfamiliar with parallelism, by allowing him or her to paste together sequential subroutines in a graph. Tracs, instead, attempts to tackle the design process as a whole, rather than

simply relieving the programmer of the need to invoke message-passing primitives.

References 1. A. Geist et al., PI.iz13 User’s Guide and

Reference Manual, Oak Ridge Nation-. a1 Laboratory, Oak Ridge, Tenn., 1993.

2 . J. Magee, J. Kramer, and M. Sloman, “Constructing Distributed Systems in Conic,” IEEE Trans. SofnLare Engi- neering,Vol. IS, No. 6 , June 1989, pp.

3 . D. Feldcamp and A. Wagner, “Parsec: A Software Development Environ- ment for Performance-Oriented Par- allel Programming,” in Transputer Research and Applications: Proc. Sixth N o d American Transputer Users Con$, S. Atkins and A. Wagner, eds., 10s Press, Amsterdam, 1993.

+. J.C. Browne, M. h a m , and S. Sobek, “Code: A Unified Approach to Paral- lel Programming,” IEEE Sojware, Vol. 6, No. 3 , July 1989, pp. 10-18.

5. J.C. Browne, T. Lee, andJ. Werth, “Experimental Evaluation of a Reusability-Oriented Parallel Pro- gramming Environment,” IEEE Trans. Sofczare Engineering, Vol. 16, No. 2, Feb. 1990, pp. 1 1 1-120.

6. G. Lobe et al., “The Enterprise Model for Developing Distributed Applica- tions,”Tech. Report T R 92-20, Dept. of Computer Science, Univ. of Alber- ta, Edmonton, Alta., Canada, 1992.

5 . A. Beguelin et al., “Grz?hical Devel- opment Tools for Network-Based Concurrent Supercomputing,” Proc. Supercomputing ’91, IEEE Computer Society Press, Los Alamitos, Calif., 1991, pp. 435-444.

663-675.

in many cases these tasks can be tested and debugged independently of other tasks. Our university department is using this technique to reuse existing sequential software (described in more detail later).

It is worth pointing o u t that we implemented behaviors as a sort of add-on to an existing Tracs prototype; attaching a behavior to a task model simply means adding a source file to tha t model. Therefore , we pre- served all the remaining features of Tracs without any further engineering effort.

M A ” G MESSAGES Tracs can automatically generate task models that perform several kinds of message analysis or manipulation - componen t s tha t can be especially useful dur ing

application development. T h e environment’s modular structure makes i t easy to take advantage of this feature with just a few mouse actions: Click on a button to create a new task; choose the appropriate predefined task model from a pop-up menu; draw a couple of lines to place the new task in the middle of the connection to be monitored. The programmer can easily customize the predefined task model to perform several operations on messages, such as computing statistical properties (total number , total size, average size, and so on), saving and/or a l ter ing their content , changing their relative order, and simulating network partitions.

Not only is this feature a simple yet powerful way to simplify many aspects of application development, i t also supports the implementation of integrated testing and

Spring 1995 47

u n i o n m a r s s w i t c h ( i r L t i) {

case 1: i n t k : c a s e 2 : f l o a t 1; default: c h a r ch: I ;

s t r u c t e a r t h I i n t i : s t r u c t e a r t h * n e x t :

I ; t y p e d e f s t r u c t e a r t h moon;

s t r u c t MYMODEL i n t o p [ ? - ] ; i n t * k ; moon p ;

op (FIXED LENGTH = 2) : 97 98

5 k : -->

P :

h (VARIABLE LENGTH = 2) : 5 . 5 0 0 0 0 0 6 . 6 0 0 0 0

s t r : b y e b y e ! ----------------

Figure IO. The first part (a) is a message model (MYMODEL) in XDR syntax. The message model uses the union (variant record) mars and the list of integers moon, which are examples of user-defined types (Figure 1). Fields h and s t r in MYMODEL are varying-length arrays; the number within angle brackets represents the maximum array size allowed. The second part (b) is a message instance of this model in human-readable textual form, according to the syntax proper of the Tracs tool mentioned in the text. The list of integers headed by p is composed of two items. The discriminant of the union is 2; therefore, the union contains a f l o a t item. Arrays h and s t r contain two and nine items, respectively.

debugging tools. Although intrusive on execution time, it is not intrusive on software. Because the programming model uses local names for intertask communication, message manipulation tasks can be freely inserted and removed without changing the code of the application being developed. The programmer-written tasks do not even have to be compiled again, so this approach is quick- er and reduces the possibility of errors due to a mismatch of versions of the various executables.

The following message analysis and manipulation operations, which can be customized or mixed without modifymg the system, are available:

saving the message on a file, delaying the message until the programmer hits a key, allowing the programmer to manually edit some field(s) of a message, computing some statistical properties of messages in transit , simulating network partitions, simulating message losses according to a given probability, inserting either fixed or variable delays, connecting an output port to a file,

connecting an input port to a file, and combining the two preceding operations to implement a playback capability.

A Tracs tool simplifies the customization of these operations, as well as the development of new ones. Given the description of a message model, the tool generates routines that implement file VO for messages following that model. Messages are stored in files in a human-readable form (as shown in Figure 10).

Other easily performed operations include altering the relative order of messages, which can be useful in many settings. For instance, the programmer might choose a random order to simulate different routings on wide-area networks, an order previously saved on a file to attempt to replay a specific execution, or an order that depends on the content of messages themselves to implement causal delivery protocols.

All the message manipulation functions are implemented on top of the filter behavior outlined earlier. Each task thus executes a loop in which it gets a message, performs some specific computation, and then forwards the message to its real destination. (This applies to both ports and services.) The implementation is


Table 1. Performance figures for runtime support on the DEC-RISC 2100 running Ultrix 4.1.

MESSAGE SIZE USER TIME SYSTEM TIME PERCENTAGE (BYTES) (I4 (P4

somewhat complicated because the code for manipu- lating a given message depends on the corresponding message model. Transparently to the programmer, however, a simple software tool creates the proper task model tailored to the specific message model. There- fore, this is not simply a library of task models, because each task‘s code depends on its interface.

Status and performance results We have implemented a Tracs prototype providing support for C, C++, and Fortran. The graphic interface, based on OSF/Motif, runs on IBM RS6000 and DEC- RISC machines. The various software tools run on several versions of Unix (Aix 3.1 for IBM RS6000, Ultrix- RISC 4.1 for DEC-RISC, SunOS 4.1.3 for SunSparc, Linux 0.99~113 and FreeBSD 1.0.0 for iAPX486). Through the graphic interface, the programmer can define and run distributed applications involving tasks allocated on any of these platforms. Our original runtime support runs on these same platforms. We have recently completed a new version of runtime support that runs on top of the PVM3 library, which should greatly enlarge the set of supported platforms as well as facilitate future system maintenance.

Table 1 reports some performance figures for a pair of sender and receiver tasks that communicate through a port. The entries labeled “local” mean that both the sender and the receiver tasks were placed on the same mache ; “remote” me‘ans that they were placed on different machines. For each experiment, we performed at least 400,000 iterations, and we measured the average virtual programmer time and the average virtual system time. The last column shows the percentage ratio between virtual programmer time and total virtual time (virtual programmer time plus virtual system time). That column shows the performance cost of the runtime support: since both the asynchronous send and the receive operations are eventually translated into one Ultrix system call, the last column shows how much the programmer has to pay in overhead compared to the native socket mechanism.

The current prototype does not directly support interaction of applications developed in Tracs with other independently developed programs. Overcoming this limit should be fairly easy, however, since both the control information attached to Tracs messages and the communication protocols adopted by the Tracs runtime support are simple.

In addition to using Tracs as a teaching tool with undergraduate computer engineering students, our

Asvnchronous send Local a 24 1,182 1.99

aoo 25 2,091 1.18 Remote 8 43 1,403 2.97

800 54 2,650 2.00 .

Re c e i v a Local 8 20 256 7.81

aoo 21 631 3.22

506 4.89 Remote 8 24 243 8.98

~~

26 ~~

aoo

department is using it as a research tool. Among other things, we have used Tracs to facilitate reuse of existing sequential software written in Fortran. This software, consisting of a large body of programs developed by another research group, simulated certain telecommu- nication systems. Since the corresponding algorithms could be modeled according to the task farm paradigm, we used the sequential code features described earlier to parallelize these programs automatically. Now we can split up the simulations and distribute them across a set of networked workstations to take advantage of their aggregate computing power. Minimal changes to the original software were necessary only because wrap- ping the Tracs-generated code around the user-provided (sequential) code requires the latter to comply with a certain interface.

racs exploits modularity in an original way. ts support of message models, task mod-

els, and architecture models as basic design components provides programmers with T a framework that has proven practical,

powerful, and easy to understand. Furthermore, modularity has allowed us to add advanced facilities to the environment, with little implementation and integration effort. From this point of view, our choice of supporting message models as a basic design component has proven appropriate. We believe that several of the ideas explored in Tracs will be useful in future work on programming environments for parallel and distributed systems. @

ACKNOWLEDGMENTS Grants from the ,%istero dell’universiti e della Ricerca Scientifica e Tecnologica, Italy (MURST 40%), and from the Commission of the European Community, Brussels (Esprit 111, Tracs, project no. 6373), supported the work described here. We are grateful to the students who participated in coding the prototype: Nicola Bertini, Luigi Cardile, Giuseppe Fedele, Marco Giusti, Giovanni My, Graziano Previato, Guido Pazzaglia, and Massimo Zema. Finally, we are grateful to Mike Schroeder and the anonymous referees for their helpful suggestions.

Spring 1995 49

REFERENCES 1. XDR External Data Representation Standard, Sun Illicrosystems,

Mountain View, Calif., 1987.

2 . D. Feldcamp and A. Wagner, “Parsec: ASoftware Development Environment for Perfonnance-Oriented Parallel Programming,” in Transputer Research and Applications: Proc. Sixth North Ameri- can Tramputer Users Con., S. Atkins and A. Wagner, eds., IOS Press, Amsterdam, 1993.

Albert0 Bartoli has been a faculty member at the Department of Infor- mation Engmeering of the University of Pisa since July 1993. His research interests include programming environments for parallel and distributed systems, operating systems, and virtual synchrony. He received his degree in electronic engineering, cum laude, in 1989, and PhD in computer enginnering in 1994, both from the University of Pisa.

Paolo Corsini is professor of digital computers at the Engineering Fac- ulty of the University of Pisa. His research interests include multimi- croprocessor systems and computer architecture. He received his degree in elec~ronic engineering, cum laude, from the University ofPisa in 1969.

Gianluca Dini has been a faculty member at the Department of Infor- mation Engineering of the University of Pisa since July 1993. His research interests include programming environments for parallel and distributed systems, management of information in large scale sjw tems, and data replication. He received his degree in electronic engineering from the University of Pisa in 1990 and is a PhD candidate with a doctoral dissertation on programming networked workstations.

Cosimo Antonio Prete is associate professor of computer engineering at the Engineering Faculty of the University of Pisa. His research interests include cache memories, multiprocessor organiza- tion, and programming environments for parallel and distributed systems. Prete is associate project manager of the Esprit Tracs project for the University of Pisa and a member of IEEE Computer Society. He received his degree in electronic engineering, cum laude, in 1982 and his PhD from the University of Pisa in 1989.

The authors can be reached a t the Dipartimento di Ingegneria dell’Informazione, Universiti di Pisa, Via Diotisalvi 2 , 56126, Pisa, Italy; Internet: [email protected]:

Schedding and Load Balancing in Parallel and Distributed Systems

Parallel Computers: Theory and Practice

edited by Beh;ooz A. Shirazi, Ali R. Hurson, and Krishna M. Kavi edited by Thomas L. Casavant, Pave1 Tvrdik, and Frantisek Plasil

Discusses how to schedule the processing elements operations to achieve expected performance goals, such as minimizing execution time, minimizing communication delays, or maximizing resource utilization. The book focuses on the future directions of the static scheduling and dynamic load balancing methods in parallel and distributed systems. It provides an overview and a detailed discussion into a wide range of topics from theoretical background to practical, state- of-the-art scheduling and load balancing techniques.

Contents: Introduction Static Scheduling Task Granularity and Partitioning Scheduling Tools Load Balancing Mechanisms for Task Migration Load Indices

448poges. April1 995. Soficover. ISBN 08 186-6587-4. Catalog #BP06587 - Members $36.00/list$48.00

SOCIETY

Covers the important issues inherent to the design of effectively programmable parallel computing machines and demonstrates the difficult tradeoffs in the design of their hardware and software components. The book details the historical progression leading to the current state-of-the-art and explains the latest developments and future trends. Its text contains 12 original tutorial chapters examining architecture and network technology, operating systems and programming languages, user interfaces and programming environments, and techniques to analyze and formally describe the complexity of parallel computing machines.

Contents: Architecture and Networks Programming Concepts and Languages System Software for Parallel Computers Formal Methods

395 pages. June 1 995. Hardcover. ISBN 0-8 186-5 162-8. Cotdog #BP05162-Members $43.00/List$54.00

graphical design of distributed applications through reusable components

Documents