Centre for Parallel Computing, University of Westminster, London, W1M 8JS

Transcription

1 Graphical Construction of Parallel Programs G. R. Ribeiro Justo Centre for Parallel Computing, University of Westminster, London, WM 8JS Abstract Parallel programming is not dicult, as the programs build up their complex behaviours in a similar way to the real world (i.e through the simple interaction of independent and simple entities). The parallel system engineer needs, however, a systematic method to decomposing the networks into independent ones or composing existing processes to form new networks. In this paper, we introduce a technique for the graphical construction of hierarchical networks (or congurations) of processes. The technique focuses on the concept of templates which dene reusable patterns of communication and synchronisation for processes. We introduce a set of graphical rules based on the equivalence between processes, more specically templates, and networks (congurations) of templates. The rules can be used to decompose networks of processes by substituting a single process for an equivalent sub-network of processes, or to abstract a sub-network of processes as a single process in order to simplify complex networks. Keywords: Parallel Programming, Graphical Design, Program Transformation. Introduction There is a general consensus that software systems should be constructed in a hierarchical modular way based upon the composition of software components. The underlying model commonly used to describe and implement parallel systems as a network of (hierarchical) communicating processes satises that requirement. This suggests that the software architectural description (network or, as we usually call it, \conguration" of processes) is essential for all phases of the development of parallel software from specication, which can be seen as a conguration of component sub-specications, to evolution, as changes to a system conguration can be carried out dynamically during the system execution by removing or including new processes. To simplify the construction of congurations, graphical notations have been widely used [,,, ]. The graphical representation of a parallel program conguration is usually simple. It includes icons (usually boxes or circles) to denote processes, lines to denote communication or synchronisation paths between processes and arrows to represent the ow of messages between the processes. Semantics for congurations of processes has also been proposed [, ]. The semantics is usually dened in terms of the structure of the conguration (structural semantics [, ]) that gives information about nodes (processes), ports and links. However, we also need information about the states and external events the conguration can perform which are dened by a behavioural semantics [,, 8]. Several attempts have been made to combine the structural and behavioural aspects of a conguration in the same graphical representation. A simple way of doing this is to include behavioural expressions for the links of each process. Another approach is to ap-

2 ply the concept of timing thread [9] that species the ordering of events of the processes' ports (interface). These notations, however, usually complicate the diagram. One problem encountered is that, in general, there is no technique for semanticpreserving transformation or verication of the behavioural properties of the conguration using the graphical notation directly. This is usually done on the textual (behavioural) specication of the conguration, for example, using the formal description of the conguration written in a CCS [8] or CSP [] specication of the conguration. In this paper, we show that the concept of template [0, ] can be used to dene rules that allow us to transform (abstract or decompose) graphically congurations of processes. The rules relate templates and congurations of templates that are behavioural equivalent. Thus, we can transform a conguration by substituting a conguration of templates for an equivalent template (abstraction) or by substituting a single template for an equivalent conguration of templates (decomposition). These rules are important during the development of parallel programs. Abstraction can be applied, for example, to reduce the number of processes of a conguration. Deadlock-freedom properties can, therefore, be checked more easily. Also, during the allocation of the processes to the target architecture, we usually need to alter the number of processes { sometimes there are too many processes, and sometimes there are too few. This means that congurations have to be serialised into single processes (abstraction), or processes have to be parallelised into congurations of processes (decomposition). In this paper, we will concentrate on two kinds of templates, namely, IO-SEQ and IO-PAR, that we have been using in many applications, and the graphical rules associated with them. The remainder of the paper is set out as follows. Section reviews the concept of template (focusing on the IO-SEQ and IO-PAR templates) and its graphical representation. In Section, the rules are introduced. Section covers examples of the use of the rules in the construction of congurations. Finally, Section presents comments and directions for future work.. The Concept Of template A template, basically, denes a type of synchronisation or communication pattern that a process can perform. We can identify many of these patterns that dene the behaviours of general processes. For instance, a process server generally behaves as follows. It receives requests from several client processes, selects one of them, performs some activity for the chosen client and at the end sends back the result. We have studied several types of templates but for brevity we will concentrate on only two of them. The rst template is called IO-PAR and denes a process that sends and receives messages in parallel. More formally, if we assume the alphabet of an IO-PAR process P to be P, then the behaviour of P is dened by the following traces []: traces(p ) = INTERLEAVES (P ) [ (INTERLEAVES(P ) ^ traces(p )) () where the function INTERLEAVES computes permutations of events and the function INTERLEAVES applies INTERLEAVES to the powerset of the process' alphabet. The

3 denition above determines that the traces of P are described by all interleavings of events in the alphabet. The second template is called IO-SEQ and corresponds to a process that receives a set of messages in parallel, performs some computation and sends another set of messages. In this case, the traces of an IO-SEQ process Q with alphabet Q = in(q) [ out(q) are characterised by the sequences of two interleavings one for the receives and another for the sends: traces(q) = INTERLEAVES (in(q)) [ (INTERLEAVES(in(Q)) ^ INTERLEAVES (out(q))) [ ((INTERLEAVES(in(Q)) ^ INTERLEAVES(out(Q))) ^ traces(q)) () Every template is given a unique graphical notation. In the case of IO-PAR and IO-SEQ templates, a box stands for an IO-PAR template and a box divided into two segments an IO-SEQ template. Each segment corresponds to the receives and sends respectively. Other types of representations can be seen in [, ]. The templates can be composed in parallel to form congurations. In a conguration (graph), edges symbolise internal links between pairs of processes. In an edge, the source node is the process that sends messages and the target node is the process that receives the messages. If an edge is linked to only one process it means that the process can communicate with the external environment. The names of the edges { i.e. the names of the events generated by the processes are, for simplication, only named when necessary. It is worth considering an important property of the conguration graphs of IO-PAR and IO-SEQ templates. As the behaviour of the templates species all sends always occur in parallel, and all receives also occur in parallel, when several links exist between two templates in the same direction, only one edge needs to be represented in the graph because communications can occur at the same time. This means that the conguration graphs do not contain \parallel edges" between template vertices. Also, to simplify the application of the graphical rules, half of the box representing an IO-SEQ template is sometimes shaded. A box with the left side shaded describes a process that does not receive messages from the environment. Similarly, if right half of the box is shaded the process does not send messages to the environment. Figure (a) shows a conguration of IO-SEQ templates that computes an 8-point Fast Fourier Transform (FFT). Every template corresponds to a buttery process that executes a two-point FFT. Figure (b) illustrates a conguration of IO-PAR and IO-SEQ templates that simulates a simple ipop device. The IO-SEQ templates, and refer to wiring (splitting) processes. Processes and are IO-PAR templates that refer to and gates. Processes and are IO-PAR templates that refer to nor gates. The and and nor IO-PAR gates must send null values initially because the IO-PAR behaviour species that sends and receives occur in parallel. More details on how these circuits work can be seen in [].. Equivalence Rules for Templates Our technique is based on rules that dene the equivalence between templates and con-

4 R Clear 0 0 Clk Q Q.bar (a) S Preset (b) Figure : Congurations of IO-PAR and IO-SEQ templates. (a) FTT (b) Flip-op. guration of templates. Since IO-PAR and IO-SEQ templates have particular properties, we have dened a special kind of equivalence that we call p-equivalence [0]. We use the concept of p-traces (precedence traces) that denes the possible ordering (or precedence) of the events in the alphabet of a process derived from its traces. The main idea is to determinate how processes interact with IO-PAR and IO-SEQ templates, simplifying the proof of properties of congurations of templates. Instead of comparing traces of processes, we compare p-traces or the more simple initial p-traces. In this case, two processes that have the same (initial) p-traces are p-equivalent. For example, an IO-PAR template P with alphabet P has the initial p-traces: p-traces(p ) = fs j s u and u INTERLEAVES(P )g () So, every process that has the same initial p-traces of P is p-equivalent to P. Similarly, an IO-SEQ template has the initial p-traces: p-traces(p ) = ft 0 j t 0 < u and u INTERLEAVES(in(P ))g () [ ft 0 ^ t j t 0 INTERLEAVES(in(P )) and t v for v INTERLEAVES(out(P ))g. Equivalence Rules for IO-PAR templates In Figure (a) we present equivalence rules that relate congurations of IO-PAR and IO-SEQ templates with IO-PAR templates. The strategy we used to dene the complete set of rules was to systematically generate every directed graph with three nodes including IO-PAR and IO-SEQ nodes. We then proved by induction that we can apply the rules to graphs of any size. The induction cannot start with graphs of only two nodes because of the fork and join congurations shown in Rule and Rule. The rules are usually simple and easy to understand. More complex rules can be dened from the basic rules. Rule says that a conguration of two IO-PAR templates that communicate is p-equivalent to an IO-PAR template. The dotted lines denote edges that may exist but are not a condition for application of the rule. This means that Rule can be applied to any kind of conguration of two IO-PAR templates. The p-equivalent IO-PAR template sends (receives) messages to (from) the environment like both templates.

5 Rule Rule Rule Rule Rule Rule 8 Rule Rule (a) (b) Figure : Graphical equivalence rules for congurations of IO-PAR and IO-SEQ templates. In Rule, the IO-SEQ template must only send messages to the IO-PAR template but it receives messages from the environment and can also receive messages from the IO-PAR template. The p-equivalent IO-PAR template receives messages from the environment like the IO-SEQ template, and also sends (receives) messages to (from) the environment like the IO-PAR template. Rule is the reverse of Rule, as the IO-SEQ template must only receive messages from the IO-PAR template. Rule is a special rule. It corresponds to a kind of \fork" conguration where the IO- SEQ template connects a set of IO-PAR templates. In the diagram, the \ " determines that there can be an arbitrary number of IO-PAR templates. Note also that the IO-PAR templates do not communicate. If they did, we could have applied Rule, and then Rule to prove that the conguration was p-equivalent to an IO-PAR template. The p-equivalent IO-PAR template in Rule receives messages from the environment as the IO-SEQ template and also sends (receives) to (from) the environment like every IO-PAR template in the conguration. The last rule, Rule, is the reverse of Rule.. Equivalence Rules For IO-SEQ templates Unlike an IO-PAR template where the events in the alphabet may occur in any order, an IO-SEQ template imposes an ordering in the execution of the events in its alphabet such that the receives always occur before the sends. Therefore, any conguration that includes at least one IO-PAR template cannot be equivalent to an IO-SEQ template. Figure (b) introduces the basic equivalence rules for congurations of only IO-SEQ templates. Rule species a conguration of two IO-SEQ templates where the rst pro-

6 Rule 9 Rule 0 Rule Figure : Context-dependent equivalence rules for congurations of IO-SEQ templates. cess only receives messages from the environment, and only sends messages to the second process. On the other hand, the second process only receives messages from the rst process and only sends messages to the environment. The p-equivalent IO-SEQ template receives messages from the environment like the rst process, and sends messages like the second process. In Rule, the rst process is similar to Rule. However, the second process does not have to receive messages only from the rst process, it can also receive messages from the environment. In this case, the p-equivalent IO-SEQ template receives messages from the environment like both processes. Rule is the reverse of this rule. Another group of equivalence rules for congurations of IO-SEQ templates is presented in Figure. These rules are only valid in a special context (environment). The context is described as a conguration of templates. In the graphical rule, it corresponds to the conguration outside the solid line box delimited by the dotted rounded-corner box.

7 (a) (b) Figure : Congurations p-equivalent to the FFT conguration. To explain the use of the context in the rules, assume a conguration similar to that dened in Rule where the rst process also sends messages to the environment. This means that this process may send messages to the environment before the second process has received its messages from the environment. Hence, the conguration does not satisfy the behaviour of an IO-SEQ template that only sends messages (to the environment) after it has received all its messages. Rule 9, however, requires that the rst process can only send messages to processes in the environment that are part of a sequence of IO-SEQ templates receiving messages from the second process in the conguration. This condition guarantees that the processes in the sequence cannot send messages until they have received the messages from the second process in the conguration. Observe also that the dotted lines inside the IO- SEQ template indicate that it may only send (receive) messages to (from) that particular environment { that is, the sends (receives) are internal if we consider the conguration together with the sequences of processes in the environment. Similar conditions are required by Rule 0 which is the reverse of Rule 9. Rule is the more complex rule. It is a generalisation of Rule. It requires that all processes that send messages to the environment can only do so after receiving the messages from all processes that receive messages from the environment. This guarantees that the sends only occur after all receives. The context is similar to the combination of the ones of Rule 9 and Rule 0.. Using the Equivalence Rules. Simplifying Congurations One of the main applications of the rules is in the simplication of complex congurations. For example, the conguration in Figure (a) can be proved to be p-equivalent to a single IO-SEQ template. The rst step of the proof is to rearrange the processes as Figure (a) shows. It then becomes clear that we can apply Rule to each of the two sub-congurations. The result is the p-equivalent conguration in Figure (b). This conguration satises Rule, therefore it is p-equivalent to a single IO-SEQ template. Figure illustrates congurations p-equivalent to the ipop in Figure (b). In Figure (a), each one of the two sub-congurations can be substituted by p-equivalent

8 R Clear R Clear R Clear Clk Q Clk Q Clk Q Q.bar Q.bar Q.bar S Preset S Preset S Preset (a) (b) (c) Figure : Congurations p-equivalent to the ipop conguration. IO-PAR templates by applying Rule. Therefore, the conguration in Figure (b) is p-equivalent to the ipop conguration in Figure (a). Also, by Rule, the subconguration in Figure (b) is p-equivalent to an IO-PAR template. This shows that the conguration in Figure (c) is also p-equivalent to the ipop conguration.. Decomposing Congurations As we said, the rules can also be applied to the decomposition (renement) of a con- guration. This is illustrated by a Hospital Monitoring System. The main components of the system are: doctor, nurse, pharmacist and patient. The doctor receives information from the patient about his/her condition, and reports from the nurse about the patient's progress. He/She then sends instructions to the nurse about the the treatment to be applied to the patient. The nurse monitors the patient, and requests the pharmacist to send the prescribed medicine. We assume that the system starts when the nurse requests data about the new patient, informs the doctor he/she has started, and asks the pharmacist to get ready. However, the doctor, the patient or the pharmacist may arrive before the nurse. In this case, we associate an IO-PAR template with the Nurse process to indicate that possibility. The patient waits for treatment from the nurse, and sends information about his/her state to the doctor and the nurse. So, the Patient process behaves like an IO-SEQ template. The doctor receives information from the nurse and the patient, and asks the nurse to apply the treatment. In this case, the Doctor process also behaves like an IO-SEQ template. Finally, the pharmacist only receives requests from the nurse and sends back the medicine. This corresponds to a simple IO-SEQ template behaviour. The graphical solution to the Hospital System using IO-SEQ and IO-PAR templates is presented in Figure (a). The decomposition strategy depends on the particular design. In general, we try to increase the strength of each module (in our case processes), and reduce the coupling among modules. Figures (b) and (c) show two possible decompositions for the Nurse process (module). In Figure (b), the decision was to decompose the Nurse process' function into three sub-functions performed by dierent processes: Collect Data, Store and Compute and Generate Reports and Requests. Applying Rule to the Collect Data and Store and Compute processes, we prove that they are p-equivalent to an IO-PAR template. We can

9 Doctor Prescribed_Treatment Patient_Report Nurse Collect Data Collect_from_Doctor Store_Compute Report_to_Doctor Collect_from_Patient Apply_Treatment Patient_Symptoms Applied_Treatment Patient Patient_Condition Request_Medicine Pharmacist Deliver_Medicine Store and Compute Generate Reports and Requests Collect_from_Pharmacist Request_to_Pharmacist (a) (b) (c) Figure : Hospital conguration. then apply Rule to the (simplied) p-equivalent conguration and process Generate Reports and Requests to show that it is p-equivalent to the Nurse process, as expected. Another decomposition of the Nurse process is presented in Figure (c). Here, the data collect function was decomposed assuming that dierent consistency checks are required. Similarly, as data is generated in dierent forms the generate reports and requests function was also decomposed. To prove that the new conguration is p-equivalent to the Nurse process, Rule can be applied successively to each collect data process (Collect from Doctor, Collect from Patient and Collect from Pharmacist) and process Store Data to prove that they are p-equivalent to an IO-PAR template. Next, Rule is applied successively to this IO-PAR template and the Report to Doctor, Dose to Patient and Request to Pharmacist processes, proving also that they are p-equivalent to an IO-PAR template.. Conclusions In this paper, we introduced a set of graphical rules that relate congurations of templates to templates. These rules are very useful in the hierarchical development of con- gurations of processes because they allow us to rene a template into sub-congurations creating a lower level conguration, or abstract a conguration as a single process creating a higher level conguration. An important property of our technique is to provide a compositional proof of deadlockfreedom that is, if we prove that a high level conguration is deadlock-free, by applying the rules we can guarantee that the decomposed (lower) level is deadlock-free, since the rules preserve the behaviour of the conguration. Also, if we prove that a low level con- guration is deadlock-free and p-equivalent to a template, when we reuse that process in a higher level conguration we do not have to check its proof of deadlock-freedom. In general compositional proof of deadlock-freedom is not easy because when we compose deadlock-free processes together they can interfere with each other []. At the moment we are investigating new rules for other kinds of templates. We are also developing a graphical environment that allows us to build and analyse congurations of templates, and at the same time derive parallel programs from the congurations of templates.

10 Acknowledgments I am very grateful to Peter Welch who has given many suggestions to improve this work. Special thanks also to my colleagues at the Computing Laboratory at the University of Kent, England, with whom I have shared some of theses ideas. References [] R. Milner. Flowgraphs and ow algebras. Journal of ACM, ():9{88, October 99. [] K. G. Shin D. Peng. Modeling of concurrent task execution in a distributed system for real-time control. IEEE Transactions on Computers, C-():00{, April 98. [] J. Kramer, J. Magee, and K. Ng. Graphical conguration programming: The structural description, construction and evolution of software systems using graphics. IEEE Computer, (0):{, October 989. [] T. Bolognesi. A graphical composition theorem for network of LOTOS processes. In 0th Int. Conf. on Distributed Computer Systems, pages 88{9, Paris, France, May 8 { June 990. IEEE. [] J. Parrow. Structural and behavioural equivalences of networks. ICALP 90, 990. [] J. Parrow. The expressive power of simple parallelism. In PARLE'89, pages 89{0. Springer-Verlag, 989. [] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 98. [8] R. Milner. Communication and Concurrency. Prentice-Hall, 989. [9] R. J. A. Buhr and R. S. Casselman. Architectures with pictures. In A. Paepcke, editor, OOPSLA'9: Conf. on Object-Oriented Programming Systems, Languages and Applications. ACM Press, October 99. [0] G. R. R. Justo. Conguration-oriented Development of Parallel Programs. PhD thesis, University of Kent at Canterbury, England, 99. [] G. R. R. Justo and P. R. F. Cunha. Deadlock-free conguration programming. In nd Int. Workshop on Congurable Distributed Systems, SEI, Carnegie Mellow University. IEEE Computer Society, March 99. [] P. Welch, G. R. R. Justo, and C. Willcock. High-level paradigms for deadlock-free high-performance systems. In R. Grebe, J. Hektor, S. C. Hilton, M. R. Jane, and P. H. Welch, editors, Transputer Applications and Systems '9, volume, pages 98{00. IOS Press, September 99. [] P. H. Welch. Emulating digital logic using transputer networks (very high parallelism = simplicity = performance). In Parallel Architecture and languages Europe, volume, pages {. Springer-Verlag, June 98. LNCS 8. [] J. Zwiers. Compositionality, Concurrency and Partial Correctness: Proof Theories For Network of Processes and Their Relationship. Springer-Verlag, 98.