P-RIO: Graphic and Modular Programming on PVM

Enrique Vinicio Carrera E. Dpto. Eng. Eletrica´ - PUC/Rio Cx. Postal 38063 - CEP 22453-900, Rio de Janeiro - RJ [email protected] Orlando Loques and Julius Leite CAA - Applied Computing and Automation Group Dpto. de Eng. Eletrica´ - UFF Rua Passo da Patria,´ 156 - CEP 24210-240, Niteroi-RJ´ {loques, julius}@caa.uff.br

Abstract This paper describes P-RIO (Parallel Reconﬁgurable Interconnectable Ob- jects), an object-based software construction methodology, that provides high- level abstractions to build modular concurrent programs, facilitating software reuse and system development. It is also shown the graphic interface integrated to the P-RIO support environment, that provides facilities for conﬁguration, debugging and management of parallel applications.

1 Introduction The P-RIO[1,2] environment includes a model, tools and mechanisms to build software for distributed and parallel programming. The software construction methodology embedded in the environment makes a distinction between the building of indi- vidual system modules and system construction from these modules. As in other pro- posals, for example [3,4], the concept of interconnectable modules is adopted. System elements are called modules, being a module composed of code and data, and one or more communication points called connectors. Modules are building blocks and there is no restriction on the number of modules used to implement a composed module, Connectors

Code ¤¡¤¢¤

Internal ¤¡¤¢¤

£¡£¢£ £¡£¢£

Data ¡ ¢ ¡ ¢ Pins

Figure 1: Basic Module nor in the number of nesting levels. A specialized conﬁguration language is used to specify the module composition and the intercommunication structure of an application. The methodology itself neither imposes restrictions on the language used in the building of components nor on the physical allocation of the modules of the application. For conﬁguration and reusing purposes, modules can be programmed and stored in a library. Beside improving modularity and reuse, the methodology includes a set of simple interconnection mechanisms that allow the design of complex intermodule communication structures. On the other hand, PVM (Parallel Virtual Machine)[5] does not discriminate between component-implementation and component-interaction, making it harder to at- tain modularity and software reuse. Yet, the PVM creation philosophy was to support a core set of low-level primitives to which high-level layers can be added. P-RIO uses the existing PVM calls to build an easier to use communication interface and to supply a distributed and parallel programming methodology with high portability. In addition, our proposal includes a graphic interface for construction and management of parallel and distributed systems (see section 3).

2 P-RIO Concepts & Programming The concept of module (Figure 1) has two facets: (i) a type or class if it is used as a template to create operational units; (ii) an operational unit, called an instance. Primitive classes define only one thread of control, and instances created from them can execute concurrently. Composition caters for module reuse and encapsulation, that is to say, existing (primitive and composite) classes can be used to compose new classes (Figure 2). Configuration comprises the selection of instances and the definition of their interconnections. The points of interaction and interconnection between instances are defined through connectors, which are associated with their par- ent classes. Connectors are themselves classes that can be reused in different module classes. The external interface of a composite class is formed by the connectors that were explicitly exported by its internal classes. This helps to hide the internal composition of a class making visible only the connectors useful for external configuration. The connectors concentrate communication activities, and are fundamental for configuration, since they serve as a ”glue” between modules.

M5 ¡ ¡ ¢

¢ M2

¡ ¡ ¢ ¢

¡ ¡ ¢ £¢£¡£¡£ ¢

M4 £¡£

¡ ¡ ¢ £¢£¡£¡£ ¢ M1 £¡£

¡ ¡ ¢ £¢£¡£¡£ ¢ £¡£

¡ ¡ ¢ £¢£¡£¡£ ¢

G £¡£

¡ ¡ ¢ ¤¡¤¡¤¢¤ £¢£¡£¡£ ¤¢¤¡¤¡¤ ¢ £¡£

¤¡¤¡¤¢¤ £¢£¡£¡£ ¤¢¤¡¤¡¤ £¡£

¤¡¤¡¤¢¤ £¢£¡£¡£ ¤¢¤¡¤¡¤ £¡£ ¤¡¤¡¤¢¤ ¤¢¤¡¤¡¤ M3

Figure 2: Module Composition & Group Communication

Each connector contains one or more connection pins, that define the basic points for external communication. Associated with each pin are a transaction type and typed data structures (messages); bi-directional synchronous (RPC) and unidirectional asyn- chronous (datagram) are among the basic transaction types. The protocol to be used is an additional feature of the transaction, that can be selected in the configuration domain. At the moment, it is permitted to use UDP or TCP protocols, besides multicast dissemination that is optionally associated to barrier synchronization. A small set of send and receive primitives are available for communication. Additionally, select- with-guard communication constructs, based on logic expressions, auxiliary time-out functions and a mechanism for propagation of exceptions between communicating modules are also available. A group communication abstraction is supported (a group named G appears in figure 2). Making a connection to a group implies making the connection to all the members of the group. A message sent by a group member is received by every member of that group. This specialized connection may be used in various applications that require communication by message dissemination (broadcast or multicast), synchronization by means of barriers or rendez-vous, etc. As an example, we present the use of the configuration language to define an experimental system for image recognition[6], shown in figure 3. The module Edges is the basic unit of parallelization. It is interesting to note that the number of instances of Edges is specified by the parameter N Instances. This provides a convenient means to tune the performance of the system. connector Image_Type { pin Image out pin_output; }; connector Matrix_Type { pin Matrix out pin_output; pin Control in pin_input; }; connector Coef_Type { pin Coefficient out pin_output; }; Figure 3: Image Recognition System class Vision_Module { class Image { code C "image"; connector Image_Type channel_out; } mod_i; class Preprocessing { code "preprocessing"; pair connector Image_Type channel_in; connector Matrix_Type channel_out[N_Instances]; connector Coef_Type channel_sol; } mod_p; class Edges { code C "edges"; pair connector Matrix_Type channel_in; } mod_e[N_Instances]; class Classifier { code C "classifier"; pair connector Coef_Type channel_in; } mod_c; link mod_i.channel_out mod_p.channel_in; for ( i = 0 ; i < N_Instances ; i++ ) link mod_p.channel_out[i] mod_e[i].channel_in; link mod_p.channel_sol mod_c.channel_in; } application( int N_Instances ); Figure 4: Snapshot of P-RIO Graphic Interface

3 Graphic Interface P-RIO includes a graphic interface (figure 4) that provides visualization features that help to configure, monitor and debug applications. This tool allows the composition of systems graphically through selection of components and definition of their interconnection. Class compression and decompression features allow the designer to inspect the internals of composed classes and simplifies the visual exposition of complex systems. With this tool, it is also possible with simple mouse commands, to control the physical allocation, instantiation, execution and removal of modules. Dynamic reconfiguration is supported, allowing to change system composition or to reallocate modules of a running program. The graphical interface, implemented using the Tcl/Tk toolkit[7], borrows many features from the XPVM tool. Thus, it supports debugging primitives for displaying messages sent and print-like outputs. 4 Conclusion The P-RIO to PVM symbiosis strategy is intended to fuse the high-level abstractions and mechanisms offered by the methodology embedded in the environment with the portability between hardware architectures provided by PVM. Performance eval- uation tests have shown that P-RIO does not introduce measurable overheads to message communication when compared to a pure PVM system. The original PVM visualization and debugging tools can also be used with P-RIO systems. In addition, P-RIO provides a graphics interface that supports class composition and the descrip- tion of application configurations. Prototypes of parallel systems can be quickly assembled using the P-RIO environment, and its graphical tool. This facilitates experimenting with different solutions for a particular scientific problem. We believe that engineers and scientists, with very lit- tle training, can build relatively complex concurrent systems using P-RIO. The system and the graphical interface are fully operational and have been used to build several experimental applications. A PVM style manual is being finished and shortly P-RIO should be available to the academic community.

5 Bibliography [1] Carrera E., Loques O., Leite J., P-RIO: The RIO Methodology on PVM, Fifth Biannual Int. Conf. on Parallel Computing, Gent - Belgium, September 1995 (ac- cepted for presentation). [2] Carrera E., Loques O., Leite J., P-RIO: The RIO Methodology on PVM, Thirteenth Brazilian Symposium of Computer Networks, Belo Horizonte - Brazil, May 1995 (in portuguese). [3] Kramer J., et al., Configuring Object-Based Distributed Programs in REX, Soft- ware Engineering Journal, V. 7 (2), March 92. [4] Allen R., Garlan D., Beyond Definition/Use: Architectural Interconnection, Work- shop on Interface Definition Languages, Portland - USA, January 1994. [5] Geist A., The PVM Concurrent Computing System: Evolution, Experiences, and Trends, J. Parallel Computing, April 1993. [6] Carrera E., Perelmuter G., Vellasco M., Pacheco M., Image Classification Using Artificial Neural Networks, Int. Conf. on Education, Practice, and Promotion on Computational Methods in Engineering Using Small Computers, Macao, July 1995. [7] Ousterhout J., Tcl and the Tk Toolkit, Addison-Wesley, 1994.