Pattern Specification in a Visual Parallel Programming Language

Transcription

1 Pattern Specification in a Visual Parallel Programming Language A. S. M. Sajeev Department of Software Development, Monash University, Australia sajeev@insect.sd.monash.edu.au Abstract Parallel Programming is significantly more complex than sequential programming because the programmer has the additional task of specifying processes, their communication and synchronization. Within the context of a visual environment we propose a two-level approach to parallel programming. The first level is the specification of a pattern encapsulating process creation and communication, and the second level is the use of patterns for parallel programming. This approach encourages reuse of patterns, and has the additional advantage that programmers who are experts in parallel programming can create patterns to be used by others who can concentrate on the sequential aspects of the program. Patterns can be exted to develop other patterns through the mechanism of object-inheritance 1 Introduction Visual programming languages have the potential to reduce the complexity of programming by providing visual means for program creation [1]. A number of visual programming languages exists, mostly in the sequential domain. Parallel programming is a more complex activity than sequential programming because the programmer has to deal additionally with creation of processes, and communication between them. So, if visual programming is useful in the sequential domain, it is likely to be more useful in the parallel domain. We have designed a visual parallel programming language called V4P based on the 4P paradigm [2]. V4P provides visual support for programming the parallel side, while the sequential aspects are programmed textually. The assumption is that generally programmers are comfortable with sequential programming and needs additional support for parallel programming. A key feature of V4P is its facility to store high-level patterns of parallel programming in a pattern-repository. A pattern is a description of communicating objects and classes that are customized to solve a general design problem in a particular context [3]. Once a pattern is specified and stored, other users can use them to create their parallel programs. V4P has certain built-in patterns; but expert parallel programmers can introduce additional patterns into the environment. This paper discusses the specification and use of patterns in V4P. In the next section we describe V4P and its base coordination language 4P. Section 3 describes the specification of patterns. Section 4 gives an example of specifying processor-farm as a pattern and its use in programs. Section 5 describes the use of inheritance in exting patterns. Section 6 discusses related literature and Section 7 gives the conclusions. 2 Visual 4P V4P provides a flexible object-oriented visual environment for parallel programming. While it uses nodes to represent objects and edges to represent communication channels, the power of the language comes from its ability to accept reusable patterns for parallel programming. The aim is to let sequential programmers create parallel programs without having to write code for process creation, communication and synchronization. V4P is based on the 4P paradigm. 4P, by introducing a very small number of constructs, lets parallel programs to have the 'look and feel' of sequential programs. 2.1 Procedures with preconditions as parallel programs (4P) 4P is a coordination language that can be attached to a sequential object-oriented language to get a concurrent object-oriented language. 4P introduces coordination in terms of two features: one, messages between objects can be synchronous or asynchronous, and two, each method has a guard attached to it; a method invocation is delayed until its guard becomes true.

2 Two objects communicate synchronously by one object calling a method of another (which is the default), and asynchronously, by an object sinvoking a method of another. In the case of s, the ser continues execution without waiting, while a new thread is spawned to execute the method invocation. Each method has a guard (by default TRUE). The three types of guards are boolean, access and path. Access guards specify modes of access to objects (Eg. exclusive), while path guards specify execution history. Details are in [2]. Here we show a boundedbuffer example written using 4P model. We use this buffer in one of the patterns in Section 5. (For the sequential code in this paper, we use Object-Pascal. The reason is that V4P is being implemented in Delphi, and the underlying language of Delphi is Object Pascal 1.) The buffer has two methods, get and put. The get method has a guard to delay calls until there is an unconsumed item in the buffer. The exclusive access to the variable next ensures that two calls to get will be executed mutually exclusively. Similar is the case for the put method. However, if the buffer is neither empty nor full, an invocation of put and another of get can run simultaneously. 2.2 Visual Interface to 4P In V4P, a programmer develops a parallel program by first creating its process communication model visually and then writing mostly the sequential code for the different nodes in the model. The visual representation of a program has at the primitive level a number of nodes. A node may have zero or more ports. Links from other nodes can be connected to a Interface const MAX = 99; type TItem = class; {forward declaration} TBuffer = class private buffer : array [0.. MAX] of TItem; slot : integer := 0; next : integer := 0; function get : TItem; procedure put (item : TItem) Implementation [Exclusive next; next < slot] {guard} function TBuffer.get : TItem; get := buffer[next MOD MAX]; next := next + 1 [Exclusive slot; slot next > 0] procedure TBuffer.put (item : TItem); buffer[slot MOD MAX] := item; slot := slot Because of shortage of space, we do not show all Object- Pascal details in the examples. In Delphi's Object Pascal we can control the visibility of private and protected variables through properties. Instead of showing properties, we have just shown the variables in the section. port. A node typically is a visual representation of an object. A port is internally represented by a method of the object. A port has a guard attached to it; an invocation to the method attached to a port is delayed until its guard holds. The figure above shows the main menu of the V4P environment. A programmer may build the program using the primitives (nodes, links and ports), or more easily, use a pattern. Once a pattern is selected, the programmer needs to write the code for each node. Creating process-threads, buffering data for communication etc. are automatically done by the system. Deping on the pattern used, the programmer may even not have to specify the guards, thereby essentially writing a sequential program. 3 Patterns In any visual environment for parallel programming the level of support provided to create programs is important. An environment may choose to provide only primitives like nodes and links; the advantage is that the programmers can then create parallel programs of arbitrary structure. However, they need to do it from scratch every time, and they need to be experts in parallel programming. On the other hand, an environment that provides only high level models like farms and pipes, while reducing the effort on the part of the programmer, makes the environment less flexible; all programs have to conform to the predefined models. Our approach is to provide both primitives and high level models as

3 patterns, but more importantly allow the creation of new patterns, either as extensions of existing patterns (using the inheritance mechanism of objectorientation) or as entirely new patterns. In this section we discuss the specification and use of patterns. Currently patterns are specified textually and used visually. There is no separate language for specifying patterns; we use the same underlying language, the one used to specify the class descriptions of the nodes. 3.1 Primitives The primitive classes in the system are TNode, TLink and TPort. The interface of these classes are defined as: TNode = class TPort = class owner : TNode; {owner of a port} guard : String; method : String; TLink = class {a link connects a node to a port of another node} head : TNode; tail : TPort In the specification of patterns, often one needs to use arrays of nodes, links and/or ports. The interfaces to TNodeArray is specified below. It uses an enumerated type: TValueTime = (patterndesigntime, programdesigntime, runtime, anytime); TNodeArray = class size : integer; node : array [1..size] of TNode; procedure setsizeat(when : TValueTime) The setsizeat method tells when the size of the array is available. If it is specified as programdesigntime, then when a user, while developing a program, chooses a pattern which contains a node-array, a dialog box would appear asking for the number of nodes. TLinkArray and TPortArray declarations are similar to that of TNodeArray except that they have arrays of TLink and TPort classes respectively. 3.2 Specifying Patterns A pattern is specified in terms of the kind of nodes it has, the port(s) for each node, the links between the nodes, and optionally the guards and methods for each port. If the guards and methods are not attached to a port in a pattern, then the user of the pattern will need to attach them at program (as opposed to pattern) design time. 3.3 Specifying a processor farm pattern A processor farm generally consists of a master process and several workers. A master divides the task into several subtasks and asks the workers to solve the subtasks. Each worker after completing its task will return the result to the master, who will 'accumulate' the partial results to construct the complete result. There are several variations of this pattern; we will discuss some of them later in the paper. The aspects common to different variations can be abstracted into an abstract farm class. It specifies a master node and an array of worker nodes. The master has a result port and an array of result links to link the result port to the workers (for them to return the result of subtasks). We specify that the result port is attached to a method called accumulator, and the guard for the method is exclusive accumulator (i.e. exclusive access to accumulator). The abstract farm also has an array of problem-ports and problem-links for the master to s subtasks to workers. TAbstractFarm = class(tpattern) master : TNode; resultport : Port; resultlink : TLinkArray; worker: TNodeArray; problemport : TPortArray; problemlink : TLinkArray; constructor create; constructor TFarm.create; var i :integer; resultport.owner := master; resultport.method := 'Accumulate'; resultport.guard := 'Exclusive accumulator'; for i := 0 to worker.size-1 do resultlink[i].head := worker[i]; resultlink[i].tail := resultport

4 In the common form of processor farm, each worker has a port (problemport) to receive the problem (i.e., the subtask) it has to solve. This port is linked to the master. A method, called solve, is attached to the port. The processor farm pattern can be specified as a descant of the abstractfarm. When an instance of the processor farm (TFarm, below) is created, it first executes the parent's create to establish the resultport and resultlinks. Then it sets up the rest of the ports and links (see the create method below). TFarm = class(tabstractfarm) constructor create; override; constructor TFarm.create; override; var i :integer; inherit; //Execute the parent's create worker.setsizeat(programdesigntime); problemport.size := worker.size; problemlink.size := worker.size; for i := 0 to worker.size-1 do problemport[i].owner := worker[i]; problemport[i].method := 'solve'; problemlink[i].head := master; problemlink[i].tail := port[i]; The pattern-programmer can attach a title (by default, the class name), an icon, and a natural description to the pattern and store it in the pattern repository. 4 Using patterns to create parallel programs To use a pattern to create a program, the first step is to choose a pattern, either by double clicking on its icon or by selecting it in the drop down menu. In this section we illustrate the use of the processor farm pattern specified in the previous section. When a user double clicks on its icon, a dialog box appears. It asks for the number of worker nodes, since the pattern specification states that the number of workers will be specified at program design time. Closing the dialog box after entering a value for the number of workers, will display a graph for the farm pattern. The user can now double click on any of the nodes, to get a code editor to enter the class description corresponding to that node (see Figure below). If the code already exists, it could be attached to the node. In the processor farm, it is often the case that each worker is an instance of the same class. Thus all worker nodes will be attached to the same TWorker class. Hence the code can be written once, and then attached to each worker node. 4.1 An Example To illustrate the use of the farm pattern we can

5 program parallel sorting as a farm. A master divides the given list of numbers into sublists. Each worker sorts a sublist in parallel with other workers and returns the sorted sublist to the master. The master merges the sorted sublists to get the final output. The master class is defined as: {We assume that the list size is a multiple of number of workers} TMaster = class private // the sorted array accumulator : array[0..99] of integer; // unsorted array initlist : array [0..99] of integer; listsize : integer = 100; sublistsize : integer; mergedlistsize : integer = 0; constructor create; procedure accumulate(sublist : array of integer); // merge constructor TMaster.create; var i, j : integer; {read the numbers} sublistsize := listsize div worker.size; for i := 0 to worker.size-1 do for j := 0 to sublistsize-1 read (sublist[j]); s worker[i].sort(sublist); procedure TMaster.accumulate( sublist: array of integer); for i := 0 to high(sublist) do for j := 0 to mergedlistsize-1 do if sublist[i] < accumulator[j] then break; insert(sublist[i], accumulator, j) {inserts sublist[i] in the accumulator at position j --details not shown} mergedlistsize := mergedlistsize + sublistsize; The worker class is defined as: TWorker = class procedure solve( sublist : array of integer); TWorker.solve( sublist: array of integer); sort(sublist); // details not shown s master.accumulate(sublist) This is essentially a sequential program except for the s-invocations used when an object does not expect a return value. The code to instantiate N workers and one master is generated automatically. The application programmer does not have to worry about synchronization because the farm pattern has already specified the only synchronization required in this case. When workers finish calculating the results, they s-invoke the master's accumulate method. The execution of the method body will be delayed until there is exclusive access to the accumulator. 5 New patterns by inheritance We can create new patterns by inheriting from already created patterns. To demonstrate this, we will create an aga farm as an extension of the farm. An aga farm has an aga object where the master will initially keep the aga items for workers to pick up (instead of directly sing them to the worker). An aga farm is useful in situations where the workers while working on a subtask needs to create new subtasks; they can place such subtasks on the aga for workers who become free. An aga farm, apart from workers and a master needs a node for the aga. An aga is essentially a buffer. So, we use the class TBuffer defined in Section 2 for aga. The aga has two ports: one to deposit the problems (problemport) and the other for workers to retrieve the problems (getport). ProblemPort is inherited from TAbstractFarm and getport is declared within TAgaFarm. TAgaFarm = class(tabstractfarm) aga : TBuffer; getport: TPort; getlink : TLinkArray; constructor create; override; constructor TAgaFarm.create;override; inherit; {Attach the problemport to put method of Aga; we need only one problem port} problemport.size := 1; problemport[0].owner := aga; problemport[0].method := 'put'; {Attach the getport to get method} getport.owner := aga; getport.method := 'get'; {Since the guards are already defined for put and get in the Tbuffer class, they will be automatically assigned to the respective guard fields} worker.setsizeat(programdesigntime); getlink.size := worker.size;

6 problemlink.size := worker.size + 1; {Link problemport[0] to master} problemlink[0].head := master; probelmlink[0].tail := problemport[0]; {Link problemport[0], getport and resultport to all workers} for i := 0 to worker.size-1 do problemlink[i+1].head := worker[i]; problemlink[i+1].tail := problemport[0]; getlink[i].head := worker[i]; getlink[i].tail := getport 6 Related Literature Two of the representative visual environments for parallel programming are Enterprise [4] and Meander [5]. In the Enterprise model, programmers are given a fixed number of models as metaphors from a business enterprise. For example, a department is a model similar to the processor farm. The programmer only needs to type in the code for the units of the enterprise. This has the advantages similar to that of using patterns inv4p. However, unlike V4P, the Enterprise model does not let the user define any metaphors; they have to program within those supplied by the system. Meander is perhaps at the other extreme, where programming is always done with nodes and edges. Meander allows composition of the graphs creating process modules, but they don't provide the same flexibility as patterns. While patterns are templates that can be reused to create different programs, process modules are parts of a program. Darwin [6] is a language for distributed systems configuration. Users can specify the configuration of a distributed system. This is similar to patterns in V4P in the sense that a pattern specifies a configuration for parallel programs that follow the pattern. The main difference, once again, is that configurations in Darwin are not generic. Furthermore, Darwin is a language separate from the implementation language (which is C++), whereas in V4P patterns are specified in the same language as the user writes code for each node (Object-Pascal). Algorithmic skeletons [7] have been explored mainly in the functional programming area. Skeletons provide a generic mechanism to specify parallelism, and in that sense provide the same functionality as V4P's patterns. We are not aware of the use of skeletons for parallelism in either a visual or an object-oriented environment, however. 7 Conclusions V4P is a visual language for parallel programming. It provides high level patterns for parallel programming. A pattern specifies the process communication structure; the user of the pattern has only to provide essentially the sequential code corresponding to the objects. In other similar visual environments, a user is restricted to the patterns provided by the system. In V4P, however, users can specify patterns of their own and add them to the repository for reuse. Because of the object-oriented environment, patterns can be created as extensions of existing patterns. Furthermore, we do not define a separate language for pattern specification. This paper has shown that creating patterns is a flexible and reusable form of developing parallel programs. Pattern development currently is textual, only their use is visual. This is acceptable since we see two classes of programmers: sequential programmers who want to create parallel programs (they can get most benefit from the visual environment), and expert parallel programmers who want to ext the already available patterns in the environment with new patterns (who wouldn't mind textual programming). We are, however, studying ways to provide a visual environment for pattern programming as well. References 1. B. A. Myers, Visual programming, programming by example, and program visualization: a taxonomy, Proc. CHI '86, 1986, A. S. M. Sajeev and H. W. Schmidt, Integrating concurrency and object-orientation using boolean, access and path guards, Proc. 3 rd Intl. Conf. High Performance Computing, Trivandrum, IEEE Press, 1996, E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design patterns: elements of reusable object-oriented software, Addison-Wesley (1995). 4. J. Schaeffer, D. Szafron, G. Lobe and I. Parsons, The enterprise model for developing distributed applications, IEEE Parallel and Distributed Technology, August, 1993, G. Wirtz, Graph-based software construction for parallel message-passing programs, Information and Software Technology Journal, 36(7), 1994, J. Magee, N. Dulay and J. Kramer, Structuring parallel and distributed programs, IEE Software Engineering Journal, 8, 1993, G. H. Botorog and H. Kuchen, Algorithmic skeletons for adaptive multigrid methods, in Lecture Notes in Computer Science, 980, Springer, 1995.