zy zyxwv Graphical Design of Distributed Applications Through Reusable Components zyxw zyxwvutsrqpo 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. zyxwvu zyxwv zyxwvuts zyx 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 appropriate of several existing methods. Our Tracs programming environment applies the latter strategy to the development of applicationsthat will be distributed across heterogeneous machines on a local network. Tracs promotes a modular approach that forces programmers to structure their applications cleanly, with welldefined 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 facilitiesas 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 zy 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 complex data structures: structures, variant records, variable-length arrays, linked lists, and so on. The programmer does not have to know XDR, however. H e 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 marshaling 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. zyxwvutsrq zyxwvutsrq zyxwvutsr zyxwvutsrqpo zyxwvut zyxwv Figure 1. A window for defining message models. instant a set of applications may be running, each comprising one or more tasks. The internal structure of each application is static, but applications can be dynamically 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 asynchronoGscommunication 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 specifiesbindings between local names during the configuration phase. The environment ensures that changing a binding does not involve recompiling the correspondingtasks. This feature makes it possible to write context-independent tasks (within the limits of use of the environment’scommunicationprimitives) - 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- 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 et e c t checks the mutual positions and speeds of ships to prevent collisions. Two tasks called f ixobj-detect and ~ 38 IEEE Parallel & Distributed Technology zyxwvutsrqponm a r e a-d e t e c t check ship movements in relation to fixed objects in the harbor (wharves, beaches, and so on) and areas forbidden to navigation. Whenever they detect a dangerous situation, 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 communicatewith ship-manager viaservices. The other tasks interact via ports. zyxwvuts zyxwvutsrqp zyxwvutsr zyxwvu 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 notifylng 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 constructors (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 restrictionson 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. Therefore, 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 rv and has two output ports, shiptx and ob jt x , both associated with message model RAD.A third output port,a r e 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- zyx zyxwvuts Spring 1995 39 Figure 3. A window for defining task models. 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 drawing in the configuration window a layout 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 messages. 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. zyxwvutsrq zyxwvutsr zyxwv zyxwvuts zyxwv zyx ciate the port with a message model chosen from a popup menu. While we are defining a task model, we can type its code into separate editing windows and split it into several files. me configurationpbase 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’sneeds, the programmer can even skip the definition phase, either in part or completely. Configuration involves 1. defining an application’slogical structure -its constituent 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 40 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 consistently. The consistency checks include logical constraints and heterogeneity constraints. Lopal constraints IEEE Parallel & Distributed Technology zyxwvutsrq zyxwvutsrq 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 constraintsinvolves cross-checkmga 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 Figure 4. A window for configuring an application. 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 correspondink endpoints. Each task model is also assoonly one compilation is made. Tracs makes remote ciated with a color, which fills all the tasks that are copies of files only when there are accessing machines instances of that model. Tasks not instantiatedyet to any that do not share the file system with the programmer's task model are filled with a different specific color. This machine. The environment also generates a group of use of color makes a great deal of information immedishell scripts for starting and killing the whole distribately available to the programmer. For instance, in a set uted application, for associating each task with a sepaof tasks, colors show which connections between ports rate window, and for attaching the standard input, outand services are allowed and which ones are not. For two put, and error of each task to files (which are also or more tasks all with the same interface (that is, all assotransparently copied back and forth, if necessary). ciated with the same sets of ports and services), colors show which ones execute the same code and which ones Architecture models do not. In an intricate graph of an application, colors show which connections carry which lund of messages. The third basic component supported by Tracs is the architecture model. Architecture models support descripWhen the programmer has successfully defined a new application, the environment generates a makefile contions of parallel programs -complete or not -that do taining all the rules for constructing the necessary exenot depend on what the single tasks actually do,2 thus cutables. Because they embody knowledge of the archisimplifylng and speeding up application development. tecture of the machines composing the system, the rules The environment provides some powerful graphic opersupport remote compilations transparently and effiations that greatly simplify the construction of archiciently. If several instances of a given task model must tectures that include repetitive substructures, such as trees and arrays. run on machines that adopt the same executable format, zyxw zyxwvuts Y zyx I'- .- Spring 1995 zyxwvuts 41 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 zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA structure. In our example, the proFigure 5. A window for designing architecture models. In designing an grammer must use the mouse to architecture model, the programmer performs actions similar to those instantiate all instances of both m and allowed in the configuration window, such as creating new tasks and defining interconnections. 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). An architecture model is a logical description of a After all instantiations have been performed, the cluster of tasks, similar to a complete application.Howarchitecture model becomes a set of tasks and interconever, an architecture model is substantially different nections in the configurationwindow (Figure 6b), allowfrom an application. For one thing, in an architecture ing the programmer to perform usual operations such as model, one or more ports or services may be left adding new tasks and changing interconnections if necunbound. Also, an architecture model is described in essary. A n architecture model can thus serve as either a terms of formal message models and formal task modcomplete application or just a starting point for further els. Afomzai message model is a message model that has design actions. only a name, without any structure. Af m a i task model In this example, the actual task model tor m behaves is a task model specified only in its interface; no code is associated with it. Furthermore, the message models as the master of a task farm; that is, it partitions the problem to be solved into many independent jobs. Similarassociated with its ports and services are formal ones. ly, the actual task model for w behaves as the worker of T o use an atchitecture model as part of an applicaa task farm; it executes a loop in which it invokes sertion, the programmer must instantiate all the formal vice s for returning the result of the previous job and task models to actual task models, which specify both getting a new one, and then carries out the new job. By the code executed by the task and the structure of the properly specializingthe various formal design compocorresponding message models. The environment then nents, we could use the example architecture model in checks to see that the instantiation makes sense - that different scenarios - for instance, in applications with the interfaces of the formal and the actual task models a client-server structure. We could even use it to build are compatible. part of the application in the harbor control system Suppose that the programmer wants to define an example discussed earlier. architecture model describing a task farm. This involves defining two formal task models: one for the master and %PE"D% SUBSTRUCTURES one for the workers. The interface of the former, m, is Tracs offers a powerful feature for handling architeccomposed of an exported service, s. The other formal ture models made up of repetitive substructures. It protask model, w, imports service s. Formal task models are vides graphic facilities that let the programmer replidefined through a window similar to the one for defincate a basic "tile," quickly and easily creating a task graph ing actual task models (Figure 3). Having defined the in which the connections between the borders of adjaformal task models, the programmer defines a task farm cent tiles are all the same. These repetitive task graphs by creating one instance of m and many instances of w include most of the useful structures: farm, ring, array, and interconnecting them properly (Figure 5). Finally, the architecture model so defined is saved for later use. grid, torus, tree, and so on. If we want to create a task graph while defining an Now, suppose that during the configuration phase, zyxwvutsrq zyxwvutsrqpon ~~~~~ zyxwvutsr zyxwvutsrq zyxwvutsr zyxwvutsr zyxwvut 42 IEEE Parallel & DistributedTechnology 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. W e 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 zyxwvutsrq zyxwvuts zyxwvuts zyxw zyxwvuts Spring 1995 Figure 6. The first window (a) shows a snapshot of the instantiationof formal task models to actual task models. A set of (previously selected) instances of the formal model w is being instantiatedto 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 configurationwindow after all necessary instantiations. The environment automatically instantiated formal service s to the actual service task -bagas a side effect of the instantiationof w to cruncher. Note that if dispatcher had not exported task-bag,the environment would not have allowed the instantiation of m to dispatcher. 43 old and new tiles contain many ports or services. How should the environment assign the connections? Including 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 insufficient 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 exactly 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 exponentialgrowth 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 Figure 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 satisfy 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 zyx zyxwv zyx zyxw 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 t o any border. 44 zyx zyxwvu IEEE Parallel & Distributed Technology zyxwvutsrqp zyxwvutsrq zyxwvutsrqp zyxwvutsrqpo third, and so on. Tracs does everything almost without intervention from the programmer, who contributes just a few mouse clicks and can undo the replication if it does not proceed 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 generating 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 automaticallyinvoked 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. zyxwv ___________- Spring 1995 45 zyxw 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 computations). 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: zyx 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 terminated 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 conjunction with the possibilityof 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 zyxwvutsrq zyxwvutsrqp 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. 46 IEEE Parallel & Distributed Technology zy Related work zyxwvu zyxwvu zyxwvutsrqp zyxw zyxwvutsrqpo zyx zyxwv 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-independence of the design components. Tracs is most similar to parse^,^ which is based on a skeleton-templatemodule approach. Parsec focuses on reusability and on finding a proper match between programs and computer architectures. It 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, componentbased 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 parallelprogramming paradigms, Tracs uses a design component called an arcbitect 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 problem 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 parallelprogramming paradigms (called assets in the system’s enterprise-based terminology). 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 parallelprogramming paradigms. Our intended 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 i n 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 a n existing T r a c s prototype; attaching a behavior to a task model simply means adding a source file to t h a t model. Therefore, we preserved all the remaining features of T r a c s without any further engineering effort. M A ” G MESSAGES T r a c s can automatically generate task models that perform several kinds of message analysis or manipulation - c o m p o n e n t s t h a t can be especially useful d u r i n g Spring 1995 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, “ConstructingDistributed Systems in Conic,” IEEE Trans. SofnLare Engineering,Vol. IS, No. 6 , June 1989,pp. 663-675. 3 . D. Feldcamp and A. Wagner, “Parsec: A Software Development Environment for Performance-Oriented Parallel Programming,” in Transputer Research and Applications: Proc. Sixth N o d American Transputer UsersCon$, 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 Parallel 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 Programming 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 Applications,”Tech. Report T R 92-20, Dept. of Computer Science, Univ. of Alberta, Edmonton, Alta., Canada, 1992. 5 . A. Beguelin et al., “Grz?hical Development Tools for Network-Based Concurrent Supercomputing,”Proc. Supercomputing ’91, IEEE Computer Society Press, Los Alamitos, Calif., 1991, pp. 435-444. application development. T h e environment’s modular structure makes it easy to take advantage of this feature with just a few mouse actions: Click on a button to create a n e w task; choose the appropriate predefined task model from a pop-up menu; draw a couple of lines to place the new task i n the middle of the connection to be monitored. The programmer can easily customize t h e predefined task model t o perform several operations on messages, such as computing statistical properties (total n u m b e r , total size, average size, and so on), saving and/or altering their content, changing their relative order, and simulating network partitions. Not only is this feature a simple yet powerful way t o simplify many aspects of application development, it also supports the implementation of integrated testing and 47 zyxwvutsr zyxwvutsrqp 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: case 2: f l o a t 1; default: c h a r ch: { I; (FIXED LENGTH op = 2) : 97 98 k --> : 5 struct earth I i n t i: s t r u c t e a r t h *next: P : 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 ; zyx zyxwvutsrqp h (VARIABLE LENGTH 5.500000 6.60000 s t r : bye bye! = 2) : zyxwv ---------------- zyxwv 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-readabletextual 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 quicker 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, delayingthe 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, 48 connecting an input port to a file, and combining the two preceding operations to implement a playback capability. zyxw 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 IEEE Parallel & Distributed Technology zyxwv zyxwvutsr zyxwvuts zyxwvutsr zyxwvut Table 1. Performance figures for runtime support on the DEC-RISC 2100 running Ultrix 4.1. MESSAGE SIZE USERTM IE (I4 (BYTES) Asvnchronous send Local a somewhat complicated because the code for manipulating 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. Therefore, this is not simply a library of task models, because each task‘s code depends on its interface. aoo Remote Receiv a Local Remote 8 800 8 aoo 8 aoo SYSTEMTIME PERCENTAGE (P4 24 25 43 54 1,182 2,091 1,403 2,650 1.99 1.18 2.97 2.00 20 21 24 26 256 631 243 506 7.81 3.22 8.98 4.89 ~~ . ~~ 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 DECRISC machines. The various software tools run on several versions of Unix (Aix 3.1 for IBM RS6000, UltrixRISC 4.1 for DEC-RISC, SunOS 4.1.3 for SunSparc, Linux 0.99~113and 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 entrieslabeled “local”mean that both the sender and the receiver tasks were placed on the same m a c h e ; “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 applicationsdevelopedin 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 communicationprotocols adopted by the Tracs runtime support are simple. In addition to using Tracs as a teaching tool with undergraduate computer engineering students, our 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 telecommunication 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 wrapping the Tracs-generated code around the user-provided (sequential) code requires the latter to comply with a certain interface. T racs exploits modularityin an originalway. ts support of message models, task models, and architecture models as basic design components provides programmers with 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 implementationand 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. @ zyxwvuts Spring 1995 ACKNOWLEDGMENTS Grants from the ,%istero dell’universiti e della Ricerca Scientifica e Tecnologica, Italy (MURST 40%), and from the Commissionof 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 MassimoZema. Finally, we are grateful to Mike Schroeder and the anonymous referees for their helpful suggestions. 49 zyxwvutsrq zyxwvutsrqponm zyxwvutsrqp zyxwvutsrq zyxwv zyxw zyxwv zyxwvutsrq 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 TransputerResearch and Applications: Proc. Sixth North American Tramputer Users Con.,S. Atkins and A. Wagner, eds., IOS Press, Amsterdam, 1993. Gianluca Dini has been a facultymember at the Department of Information Engineering of the University of Pisa since July 1993. His research interests include programmingenvironmentsfor 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 programmingnetworked workstations. Cosimo Antonio Prete is associate professor of computer engineering at the Engineering Faculty of the University of Pisa. His Albert0 Bartoli has been a faculty member at the Departmentof Information Engmeering of the University of Pisa sinceJuly 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 Universityof Pisa. research interests include cache memories, multiprocessor organization, and programming environmentsfor 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. Paolo Corsini is professor of digitalcomputers at the EngineeringFaculty of the University of Pisa. His research interests include multimicroprocessor systems and computer architecture.He receivedhis degree in elec~ronic engineering, cum laude, from the UniversityofPisa in 1969. The authors can be reached a t the Dipartimento di Ingegneria dell’Informazione,Universiti di Pisa, Via Diotisalvi 2 , 56126, Pisa, Italy; Internet: gianluca@dini.iet.unipi.it: 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, Pave1Tvrdik, 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. T h e 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, stateof-the-art scheduling and load balancing techniques. 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. T h e 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. zyxwvutsrqpon Contents: Introduction Static Scheduling Granularityand Partitioning Scheduling Tools Balancing Mechanisms for Task Migration Indices 448poges. April1 995. Soficover. ISBN 0 8 186-6587-4. Catalog #BP06587 -Members $36.00/list$48.00 Task Load Load Contents: Architecture and Networks Programming Concepts and Languages System Softwarefor Parallel Computers Formal Methods 395 pages. June 1 995. Hardcover. ISBN 0-8186-5162-8. Cotdog #BP05162-Members SOCIETY $43.00/List$54.00