Graphical Construction of Parallel Programs G. R. Ribeiro Justo Centre for Parallel Computing, University of Westminster, London, W1M 8JS e-mail:
[email protected],
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 con gurations) of processes. The technique focuses on the concept of templates which de ne reusable patterns of communication and synchronisation for processes. We introduce a set of graphical rules based on the equivalence between processes, more speci cally templates, and networks (con gurations) 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 1. 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 satis es that requirement. This suggests that the software architectural description (network or, as we usually call it, \con guration" of processes) is essential for all phases of the development of parallel software from speci cation, which can be seen as a con guration of component sub-speci cations, to evolution, as changes to a system con guration can be carried out dynamically during the system execution by removing or including new processes. To simplify the construction of con gurations, graphical notations have been widely used [1, 2, 3, 4]. The graphical representation of a parallel program con guration 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 con gurations of processes has also been proposed [1, 5]. The semantics is usually de ned in terms of the structure of the con guration (structural semantics [5, 6]) that gives information about nodes (processes), ports and links. However, we also need information about the states and external events the con guration can perform which are de ned by a behavioural semantics [5, 7, 8]. Several attempts have been made to combine the structural and behavioural aspects of a con guration 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-
ply the concept of timing thread [9] that speci es 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 veri cation of the behavioural properties of the con guration using the graphical notation directly. This is usually done on the textual (behavioural) speci cation of the con guration, for example, using the formal description of the con guration written in a CCS [8] or CSP [7] speci cation of the con guration. In this paper, we show that the concept of template [10, 11] can be used to de ne rules that allow us to transform (abstract or decompose) graphically con gurations of processes. The rules relate templates and con gurations of templates that are behavioural equivalent. Thus, we can transform a con guration by substituting a con guration of templates for an equivalent template (abstraction) or by substituting a single template for an equivalent con guration 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 con guration. 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 con gurations have to be serialised into single processes (abstraction), or processes have to be parallelised into con gurations 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 2 reviews the concept of template (focusing on the IO-SEQ and IO-PAR templates) and its graphical representation. In Section 3, the rules are introduced. Section 4 covers examples of the use of the rules in the construction of con gurations. Finally, Section 5 presents comments and directions for future work.
2. The Concept Of template A template, basically, de nes a type of synchronisation or communication pattern that a process can perform. We can identify many of these patterns that de ne 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 de nes 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 de ned by the following traces [7]: traces(P ) = INTERLEAVES ( P ) [ (INTERLEAVES( P ) ^ traces(P ))
(1)
where the function INTERLEAVES computes permutations of events and the function INTERLEAVES applies INTERLEAVES to the powerset of the process' alphabet. The
de nition 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)) (2) [
[
^
[
^
^
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 [11, 12]. The templates can be composed in parallel to form con gurations. In a con guration (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 simpli cation, only named when necessary. It is worth considering an important property of the con guration graphs of IO-PAR and IO-SEQ templates. As the behaviour of the templates speci es 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 con guration 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 1(a) shows a con guration of IO-SEQ templates that computes an 8-point Fast Fourier Transform (FFT). Every template corresponds to a butter y process that executes a two-point FFT. Figure 1(b) illustrates a con guration of IO-PAR and IO-SEQ templates that simulates a simple ip op device. The IO-SEQ templates 1, 4 and 7 refer to wiring (splitting) processes. Processes 2 and 5 are IO-PAR templates that refer to and gates. Processes 3 and 6 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 speci es that sends and receives occur in parallel. More details on how these circuits work can be seen in [13].
3. Equivalence Rules for Templates
Our technique is based on rules that de ne the equivalence between templates and con-
R 0 1
0 1
2
2 3
3
Clk
Clear
2
3
5
6
4
Q
1
4 5
4 5 6 7
6 7
S
(a)
7
Q.bar
Preset
(b)
Figure 1: Con gurations 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 de ned a special kind of equivalence that we call p-equivalence [10]. We use the concept of p-traces (precedence traces) that de nes 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 con gurations 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 ) =
s j s u and u 2 INTERLEAVES( P )g
f
(3)
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 j t < u and u 2 INTERLEAVES(in( P ))g [ ft ^ t2 j t 2 INTERLEAVES(in( P )) and t2 v for v 2 INTERLEAVES(out( P ))g 0
0
0
(4)
0
3.1 Equivalence Rules for IO-PAR templates In Figure 2(a) we present equivalence rules that relate con gurations of IO-PAR and IO-SEQ templates with IO-PAR templates. The strategy we used to de ne 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 con gurations shown in Rule 4 and Rule 5. The rules are usually simple and easy to understand. More complex rules can be de ned from the basic rules. Rule 1 says that a con guration 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 1 can be applied to any kind of con guration of two IO-PAR templates. The p-equivalent IO-PAR template sends (receives) messages to (from) the environment like both templates.
Rule 6
Rule 1
Rule 2 Rule 7
Rule 3
Rule 8
Rule 4
Rule 5
...
...
...
...
(a)
(b)
Figure 2: Graphical equivalence rules for con gurations of IO-PAR and IO-SEQ templates. In Rule 2, 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 3 is the reverse of Rule 2, as the IO-SEQ template must only receive messages from the IO-PAR template. Rule 4 is a special rule. It corresponds to a kind of \fork" con guration where the IOSEQ 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 1, and then Rule 2 to prove that the con guration was p-equivalent to an IO-PAR template. The p-equivalent IO-PAR template in Rule 4 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 con guration. The last rule, Rule 5, is the reverse of Rule 4. 3.2 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 con guration that includes at least one IO-PAR template cannot be equivalent to an IO-SEQ template. Figure 2(b) introduces the basic equivalence rules for con gurations of only IO-SEQ templates. Rule 6 speci es a con guration of two IO-SEQ templates where the rst pro
Rule 9
...
...
...
...
...
...
...
...
Rule 10
...
...
...
... ... ...
...
...
... ... ... ...
Rule 11
... ...
...
...
...
...
...
...
...
...
...
...
...
Figure 3: Context-dependent equivalence rules for con gurations 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 7, the rst process is similar to Rule 6. 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 7 is the reverse of this rule. Another group of equivalence rules for con gurations of IO-SEQ templates is presented in Figure 3. These rules are only valid in a special context (environment). The context is described as a con guration of templates. In the graphical rule, it corresponds to the con guration outside the solid line box delimited by the dotted rounded-corner box.
0 1
0 1
0 1
0 1
2
2 3
2
2 3
4 5
4 5 6 7
3 4 5 6 7
6 7
(a)
3 4 5 6 7
(b)
Figure 4: Con gurations p-equivalent to the FFT con guration. To explain the use of the context in the rules, assume a con guration similar to that de ned in Rule 7 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 con guration 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 con guration. This condition guarantees that the processes in the sequence cannot send messages until they have received the messages from the second process in the con guration. Observe also that the dotted lines inside the IOSEQ 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 con guration together with the sequences of processes in the environment. Similar conditions are required by Rule 10 which is the reverse of Rule 9. Rule 11 is the more complex rule. It is a generalisation of Rule 6. 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 10.
4. Using the Equivalence Rules 4.1 Simplifying Con gurations One of the main applications of the rules is in the simpli cation of complex con gurations. For example, the con guration in Figure 1(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 4(a) shows. It then becomes clear that we can apply Rule 11 to each of the two sub-con gurations. The result is the p-equivalent con guration in Figure 4(b). This con guration satis es Rule 11, therefore it is p-equivalent to a single IO-SEQ template. Figure 5 illustrates con gurations p-equivalent to the ip op in Figure 1(b). In Figure 5(a), each one of the two sub-con gurations can be substituted by p-equivalent
R
Clear
R Clear
4 Clk
1
2
Q
4
3 Clk
5
R Clear
1
Q
4
Q
Clk
6 7 Preset
S
(a)
Q.bar
7
S
Preset
(b)
Q.bar
7
Q.bar
S Preset
(c)
Figure 5: Con gurations p-equivalent to the ip op con guration. IO-PAR templates by applying Rule 1. Therefore, the con guration in Figure 5(b) is p-equivalent to the ip op con guration in Figure 5(a). Also, by Rule 4, the subcon guration in Figure 5(b) is p-equivalent to an IO-PAR template. This shows that the con guration in Figure 5(c) is also p-equivalent to the ip op con guration. 4.2 Decomposing Con gurations As we said, the rules can also be applied to the decomposition (re nement) 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 6(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 6(b) and 6(c) show two possible decompositions for the Nurse process (module). In Figure 6(b), the decision was to decompose the Nurse process' function into three sub-functions performed by di erent processes: Collect Data, Store and Compute and Generate Reports and Requests. Applying Rule 2 to the Collect Data and Store and Compute processes, we prove that they are p-equivalent to an IO-PAR template. We can
Prescribed_Treatment Doctor
Patient
(a)
Collect_from_Doctor
Store_Compute
Collect_from_Patient Deliver_Medicine
Patient_Condition
Nurse
Request_Medicine
Applied_Treatment
Patient_Symptoms
Patient_Report
Collect Data
Pharmacist
Store and Compute
Report_to_Doctor
Apply_Treatment
Collect_from_Pharmacist
Request_to_Pharmacist
Generate Reports and Requests
(b)
(c)
Figure 6: Hospital con guration. then apply Rule 3 to the (simpli ed) p-equivalent con guration 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 6(c). Here, the data collect function was decomposed assuming that di erent consistency checks are required. Similarly, as data is generated in di erent forms the generate reports and requests function was also decomposed. To prove that the new con guration is p-equivalent to the Nurse process, Rule 2 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 3 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.
5. Conclusions In this paper, we introduced a set of graphical rules that relate con gurations of templates to templates. These rules are very useful in the hierarchical development of con gurations of processes because they allow us to re ne a template into sub-con gurations creating a lower level con guration, or abstract a con guration as a single process creating a higher level con guration. An important property of our technique is to provide a compositional proof of deadlockfreedom | that is, if we prove that a high level con guration 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 con guration. 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 con guration 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 [14]. 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 con gurations of templates, and at the same time derive parallel programs from the con gurations of templates.
6 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
[1] R. Milner. Flowgraphs and ow algebras. Journal of ACM, 26(4):794{818, October 1979. [2] K. G. Shin D. Peng. Modeling of concurrent task execution in a distributed system for real-time control. IEEE Transactions on Computers, C-36(4):500{516, April 1987. [3] J. Kramer, J. Magee, and K. Ng. Graphical con guration programming: The structural description, construction and evolution of software systems using graphics. IEEE Computer, 22(10):53{65, October 1989. [4] T. Bolognesi. A graphical composition theorem for network of LOTOS processes. In 10th Int. Conf. on Distributed Computer Systems, pages 88{95, Paris, France, May 28 { June 1 1990. IEEE. [5] J. Parrow. Structural and behavioural equivalences of networks. ICALP 90, 1990. [6] J. Parrow. The expressive power of simple parallelism. In PARLE'89, pages 389{405. Springer-Verlag, 1989. [7] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985. [8] R. Milner. Communication and Concurrency. Prentice-Hall, 1989. [9] R. J. A. Buhr and R. S. Casselman. Architectures with pictures. In A. Paepcke, editor, OOPSLA'92: Conf. on Object-Oriented Programming Systems, Languages and Applications. ACM Press, October 1992. [10] G. R. R. Justo. Con guration-oriented Development of Parallel Programs. PhD thesis, University of Kent at Canterbury, England, 1993. [11] G. R. R. Justo and P. R. F. Cunha. Deadlock-free con guration programming. In 2nd Int. Workshop on Con gurable Distributed Systems, SEI, Carnegie Mellow University. IEEE Computer Society, March 1994. [12] 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 '93, volume 1, pages 981{1004. IOS Press, September 1993. [13] P. H. Welch. Emulating digital logic using transputer networks (very high parallelism = simplicity = performance). In Parallel Architecture and languages Europe, volume 1, pages 357{373. Springer-Verlag, June 1987. LNCS 258. [14] J. Zwiers. Compositionality, Concurrency and Partial Correctness: Proof Theories For Network of Processes and Their Relationship. Springer-Verlag, 1987.
