Communicating Process Architectures 2000 77 P.H. Welch and A.W.P. Bakkers (Eds.) IOS Press, 2000 Conditional Communication in the Presence of Priority Gerald H. Hilderink and Jan F. Broenink University of Twente, P.O.Box 217, 7500 AE Enschede Control Laboratory, The Netherlands G.H.Hilderink@el.utwente.nl Abstract. In this paper the behavior of conditional communication in the presence of priority will be described. In the theory of CSP, conditional communications are expressed by a (external) choice construct also known as the alternative construct by which the choice of one communication out of a set of communications is non-deterministic. In practice, some communication can be more important than others, so that, the choice is deterministic. Therefore, one can distinguish two prioritized alternative constructs; a symmetric alternative construct (ALT) and an asymmetric alternative construct (PRIALT). Current formal semantics and implementations of the ALT and PRIALT are based on the priorities of communication and not related to the surrounding priorities of communicating processes. This can result in a structural mismatch that can cause performance problems. In this paper a practical solution for realizing fair and unfair conditional communication in the presence of the PAR and the PRIPAR will be discussed. 1. Introduction Purely parallel languages can be given adequate semantics by models whose only primitives are communications, such as CSP failure/divergences model, since one part of a program can only influence a disjoint part by communication [13]. The theory of Communicating Sequential Processes (CSP) [6,7,14] specifies fundamental synchronization primitives, based on processes and communication between processes. Fundamental operators specify whether processes execute in sequence, in parallel, or by some choice. The interaction between concurrent processes is performed by communication via channels. Channel communication can be unconditional or conditional. Unconditional communication is when two processes communicate and conditional communication is an alternation, or a choice, between more than one communication. The essence of alternation is that it acts as an arbiter between a number of concurrently presented alternative communications. An alternation combines a number of processes guarded by communication inputs or outputs on channels. If a number of parallel processes becomes committed to communication with guarded processes then the arbiter will select exactly one communication. The alternation performs the process associated with the guard being ready. In CSP, such a conditional communication pattern is known as the alternative construct. The choice that is made is non-deterministically. Thus, in theory, the choice of one communication out of a set of communications is arbitrary. In practice, the internal choice mechanism is more or less deterministic and the implementation will always select a particular branch. Under the formal semantics any way of
78 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority making an alternative choice is legal including some random mechanism or a grossly fair one [13]. A fully deterministic mechanism is still a valid implementation of a non-deterministic specification. In software, some fairness can be desired by which each choice has equal probability or some unfairness can be desired by which some communication is more important than others. Therefore, we distinguish two prioritized alternative constructs; a symmetric (or fair) alternative construct (ALT) and an asymmetric (or unfair) alternative construct (PRIALT). These constructs are of major importance in many programs. Both constructs are legal alternatives in CSP and are defined in occam [8]. The occam language model is tightly related to CSP. We use occam for pseudo-coding the examples in this paper. A shortcoming of CSP is that it does not treat any notion of priority. Thus, the PRIALT and PRIPAR are not treated in CSP. CSP abstracts from those details and specifies the PAR and ALT being non-deterministic. In general, CSP does not specify the behavior of scheduling of processes (i.e., threads) as is done in occam. Lawrence [11] extended CSP with a general treatment of priority, called CSPP, but it is not clear whether there is a direct association between the priority of the client processes and the preferences given by the ALT or PRIALT. In occam, there is no such an association and therefore the programmer is expected to do the necessary mapping. An unfortunate mapping of PRIALTs and PRIPARs can cause a structural priority mismatch resulting in a performance penalty. In circumstances where the priority of a process is changing (due, for example, to the use of deadline-driven scheduling or priority inheritance) use of a static mapping would no longer be adequate [2]. In software, the notion of priorities is an important property of the ALT and PRIALT, but also an important property of the PAR and PRIPAR. These properties allow specifying the fairness and unfairness of scheduling of processes or choosing between events. These properties are coherently related to each other and managed by the underlying kernel. This paper illustrates the notion of priority by showing that the ALT and PRIALT should adapt their decision to the priorities of the surrounding client processes. This solution eliminates the above-mentioned mismatch problem. 2. Unconditional and conditional communication In CSP communication between processes can appear as unconditionally or conditionally. 2.1 Unconditional communication Unconditional communication is when two processes engage in communication. As described by Jones [9], the important thing about unconditional communication is that once an unconditional communication has become possible, it must happen eventually. An unconditional communication, as soon as it becomes possible, makes an offer to its peer. A process receiving an offer knows that the sender cannot withdraw the offer, because he is already committed to the communication. For example, example 1 illustrates two communicating processes. PAR chan!x chan?y - writer process - reader process Example 1: communicating processes in parallel. The writer process (chan!x) and the reader process (chan?y) run in parallel and both processes will rendezvous on the channel chan. This means that if the writer process is ready to transmit then it will block until the reader process is ready to receive. Similarly, if the reader process is ready to receive it will block until a writer process is ready to transmit. A blocked process
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 79 consumes no processor time and another process will run instead. When both processes are ready for communication one outputs on the channel and the other inputs on the channel they are engaging in the same communication event. On communications, data will be copied from source variable x into destination variable y. After communication both processes continue. 2.2 Conditional communication With conditional communications several communications between processes are under the condition that only one of them will actually happen. A decision has to be made about which one of those possible conditional communications will happen, i.e. an alternation between more than two communications. Not until that decision has been taken any of them are committed to happen. The decision between alternative communications can be based on an arbitrary choice, so called alting. In CSP, such an arbitrary choice of one of those communications introduces nondeterminism to the process that is doing the alting, i.e., it is not under the control of that alting process or anyone else. If the environment of an alting process is offering several events (e.g. channel inputs, channel outputs, timeouts, skips), the alting process makes an arbitrary choice of one of those events. Once the choice of one of those events is made the process that is followed by this event will be executed. These events are an integral part of the decision even though it is tempting to think that this process is a choice between the guarded processes. The conditional peer appears as a guard guarding the process and the other unconditional peer is not a guard. A guard consists of an event and a process, with the assumption that the process can commit in this event as the first event it must engage in. A guard is said to be ready, when there is a process already committed to this event. A conditional peer can be an input-guard or output-guard (not allowed in occam), but also a timeout-guard or skip-guard which are not treated in this paper. As mentioned in section 1, a conditional communication pattern is known as the alternative construct. When its guards are treated as being equally important then the selection criteria is symmetric, but when its guards favors over other guards then the selection criteria is asymmetric. Therefore, we distinguish two alternative constructs: the symmetric alternative construct (ALT) and the asymmetric alternative construct (PRIALT). 2.2.1 Symmetric alternative construct (ALT) A symmetric alternative construct considers each guard to be equally important. Example 2 illustrates a symmetric alternative construct with two guards each guarding a process, respectively P and Q. WHILE TRUE ALT chan1?request -- read operation: on communication read request value from chan1 -- perform process P P(request) chan2!object -- write operation: on communication write object to chan2 -- perform process Q Q(object) Example 2: alternative construct. Here, process P is guarded by chan1 and process Q is guarded by chan2. If chan1 is the only channel being ready, i.e. a client process is committed in communication on chan1, then the ALT will select the guard by successively executing the read operation chan1?request and
80 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority process P(request). If chan2 is the only channel being ready then the ALT will select the guard by successively executing the write operation chan2!object and process Q(object). The selection criterion used is that the guards have equal priorities. If both guards are ready then one of the guards will be randomly selected. If no guard is ready then the ALT will wait until at least one guard becomes ready, i.e. at least one client process is willing to communicate. The ALT terminates when the selected process terminates. 2.2.2 Asymmetric alternative construct (PRIALT) In practical situations, one event can be more important than other events. In other words, some events favors over other events. In these circumstances, the choice is asymmetric. The asymmetric alternative construct, called PRIALT, is priority-ordered and assigns declining priorities to the list of guards. WHILE TRUE PRIALT chan1?request -- read operation: on communication read request value from chan1 -- perform process P P(request) chan2!object -- write operation: on communication write object to chan2 -- perform process Q Q(object) Example 3: priority-ordered alternative construct. The selection criterion used is that the guards have different (declining) priorities. The alteration will input values from chan1 in preference to outputs to chan2. Thus, the alternation will select guard chan1?request in favor for guard chan2!object when both are ready. 2.2.3 Unconditonal and conditonal guards A guard can be conditional or unconditional (do not confuse with conditional and unconditional communication) in that each conditional guard can be enabled or disabled according to its condition of resp. true or false. A disabled guard will be omitted by the selection mechanism. Unconditional guards, as in example 3, are always enabled. Example 4 illustrates two conditional guards. WHILE TRUE ALT (t>30) & chan1?request -- read operation: on communication read request value from chan1 -- perform process P P(request) (x<y) & chan2!object -- write operation: on communication write object to chan2 -- perform process Q Q(object) Example 4: alternative construct with conditional guards. If condition (t>30) is true then chan1 will be checked otherwise it will be omitted and the guarded process P will not be selected. This is similar for the second guard. When both conditions are true, this example is equal to example 2.
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 81 2.2.4 Alting disagreement Jones [9] describes that if each process tries to communicate by a conditional communication then they must both make the same decision about whether they want to communicate. Any attempt to make the decision independently at each process is likely to lead to a disagreement, especially for truly concurrent or physically separated processors. For example, two communicating alting processes performing conditional communication at each peer will never commit in communication as illustrated in the following example: PAR ALT chan!x -- write operation: on communication write x value to chan -- perform process P P(). ALT chan?y -- read operation: on communication read y from chan -- perform process Q Q(y). Example 5: alternative disagreement. A solution is imposing restrictions on the way in which conditional communications can legally be used in programs. The restriction adopted in occam is to ensure that no pair of conditional communications ever meet. Whenever a pair of communications matches, at least one is guaranteed to be unconditional. Jones shows that the restriction is to eliminate output guards and that input guards are sufficient (programming without input guards is less natural than programming without output guards). This means that in each pair of communicating processes there is an output, which is necessarily unconditional. He illustrates that each output guard can be replaced by a communication pattern with an input guard. The following example 6 shows a replacement of the output guard of example 2 into an input guard. WHILE TRUE ALT chan1?request -- read operation: on communication read request value from chan1 -- perform process P P(request) chan3?request -- read operation: on communication read request from chan3 chan2!object -- write operation: on communication write object to chan2 -- perform process Q Q(object) Example 6: alternative construct with only input guards. The caller of chan3 must be adapted as well; first it must output a request on chan3 (chan3!request) and then it must read the object from chan2 (chan2?object). This workaround is an effective solution, but calls for extra channel communications and expansion of the communication protocol between processes. This may restrict some design
82 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority freedom and lowers efficiency. In legal circumstances an output guard may simplify the design and is faster than applying the workaround with an input guard. Instead of imposing restrictions, another solution is to allow output guards when it suites best where by the above mentioned hazard should be detected by tools before run-time and resulting in warnings for the user. These semantic rules can be checked during design to make the designer aware of possible dangers and these rules can be checked afterwards for the finishing touch resulting in errors. This can be accompanied with checking other semantic rules. We elaborate more on this issue in section 3.3. 3. Alting with notion of priority In the theory of CSP, the ALT is an arbitrary choice construct and does not specify any fairness or unfairness. Thus, any way of making a choice, i.e. fair or unfair, is legal. It must not concern the programmer or user of the alting process how the choice is made. In software, assigning priorities to the execution of processes is an important solution when processes are scheduled on a single processor and when their deadlines must be met. The underlying mechanism is often deterministic and therefore we must distinguish between fairness and unfairness to specify the deterministic decisions in software. A fair decision is made with respect to previous decisions the mechanism has made. An unfair decision can be any decision that is not a fair decision, which is trivial of course. In this paper we present the symmetric alternative construct (ALT) as the purely fair alternative construct and the asymmetric alternative construct (PRIALT) as a particular unfair alternative construct. However, there are circumstances whereby the PRIALT is preferred to be fair and not being unfair. The nature of fairness or unfairness is a matter of proper dealing with the priorities of processes and with the priorities of communication events. 3.1 Logical alting versus preference alting The PRIALT, as described in section 2.2.2, uses a most trivial deterministic mechanism and is of major importance in many programs. The unfairness (or asymmetric) criteria used are that the guards have different (declining) priorities. Roscoe [13] describes a fair alting mechanism for occam based on a PRIALT with the use of conditional input guards, see example 7. SEQ PRIALT (i 0) & g0 i = 1 (i 1) & g1 i = 2.. (i n-2) & gn-1 i = n-1 gn-1 i = 0 (i > 0) & g0 i = 1 (i > 1) & g1 i = 2..
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 83 (i > n-2) & gn-1 i = n-1 CASE i 1 2 P0 P1.. n-1 0 Pn-2 Pn-1 Example 7: alternative construct with conditional input guards. Here, gi is a guard and the CASE performs branches to the process Pi. This solution guarantees that no guard can be activated twice while there is another one waiting. The conditions provide a fair priority ordering among the guards. The fairness (or symmetric) criteria used are that the guards are round-robin prioritized with the guard chosen last time getting lowest priority next time. Still we can say that the guards under the ALT have equal priority. A slightly simpler solution or a fair ALT is given by Lau and Shea [10] using occam 2, which is basically the same as the one above. The behavior of fairness and unfairness can be described by specifying the notion of priority for each of them. The semantics of the fair ALT as described by Roscoe [13] and the PRIALT by Lawrence [11] are isolated to the alting process. These descriptions of round-robin implementation for the ALT and priority-ordering implementation for the PRIALT are basically cyclic (non-busy) polling mechanisms that test the readiness of each guard in a cyclic fashion. A description about the implementation and properties of the PRI ALT can be found in Barret et al. [1]. These implementations are for instance found in kernels of occam (including occam translators such as KroC [16] and SpoC [12]), the transputer, and the CSP for Java kernels JCSP [15] and CTJ [4]. These decision mechanisms are focused on the logical priorities of its guards and not on the priorities of its client processes. We call this alting process logical alting. Burns [2,3] noticed that the programmer is expected to do the necessary mapping. In circumstances where the priority of a process is changing (due, for example, to the use of deadline-driven scheduling or priority inheritance) use of a static mapping would no longer be adequate. For example, an unfortunate mapping of a PRIALT and its client processes in a PRIPAR can cause a structural priority mismatch resulting in a performance penalty. Even the fair mechanism of the ALT can become unfair in contrast to the priorities of the client processes. Some applications may experience more trouble than others, but for real-time applications these problems can have a significant burden on the deadlines. We think that these implementations are inefficient (i.e. not optimal) for real-time software. A solution is to adapt the decision mechanism in such a way that it is focused on the preference priority of its guards and also focused on the priorities of the surrounding client processes. Important is that the priorities of the client processes should dominate over the priorities of the guards. We call this alting process preference alting. The examples in the following subsections will illustrate the problems of logical alting and its corrections that are performed by preference alting. These examples illustrate the behavior of alting in the presence of a PAR or PRIPAR on a single processor system, because priorities relations between processes have only meaning on a shared processor. On such a system, we assume that the underlying mechanism is deterministic which always will result in a single trace of communications. The trace of communication is a sequence of communication events in order of occurrence between angled brackets <>. As we speak of an ALT we mean a purely fair ALT.
84 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority PAR c2!a c1!b WHILE i<2 SEQ -- P1 -- P2 ALT -- P3 c1?x P(x) c2?y Q(y) i:=i+1 PAR c2!a c1!b WHILE i<2 SEQ -- P1 -- P2 PRIALT -- P3 c1?x P(x) c2?y Q(y) i:=i+1 Examples 8a,b,c and d: illustrations of scheduling behavior. PRIPAR c2!a c1!b WHILE i<2 SEQ -- P1 -- P2 ALT -- P3 c1?x P(x) c2?y Q(y) i:=i+1 PRIPAR c2!a c1!b WHILE i<2 SEQ -- P1 -- P2 PRIALT -- P3 c1?x P(x) c2?y Q(y) i:=i+1 3.1.1 ALTing in the presence of a PAR. Example 8a (see above) illustrates an ALTing process communicating with two client processes in parallel. The PAR executes its processes in a round-robin fashion and starts with the first process in the list of processes. Client process P1 outputs on channel c2, client process P2 outputs on channel c1, and process P3 alternates two times to serve (read) both client processes. The PAR starts with process P1. Due to the deterministic behavior of the PAR we assume that P1 and P2 are waiting for communication when the ALT is executed. The trace of communication in this example will be <c1,c2> and this sequence is determined by the round-robin selection mechanism of the ALT. The execution order of the guarded processes is {P(x), Q(y). The selection fairly alternates between the two guarded processes P(x) and Q(y). This behavior is exactly according our expectation. This description applies for a logical ALT and for a preference ALT, because they behave equally under the PAR. 3.1.2 PRIALTing in the presence of a PAR Example 8b (see above) illustrates a PRIALTing process communicating with two client processes in parallel. The PAR starts with process P1. The trace of communication will be <c1,c2> and this sequence is forced by the selection mechanism of the PRIALT. The execution order of guarded processes is {P(x), Q(y). This behavior is exactly according our expectations. Note that the PRIALT under the PAR will get close to the behavior of the ALT when it depends on the random arrival times of the input values. In this example, the arrival times of input values are not random but strictly deterministic. This description applies for a logical ALT and for a preference ALT, because they behave equally under the PAR. 3.1.3 ALTing in the presence of a PRIPAR Example 8c (see above) illustrates an ALTing process communicating with two client processes with different priorities. The PRIPAR executes its processes in a preemptive fashion a lower priority process can be preempted by a higher priority process and starts with the first process in the list of processes. The PRIPAR starts with process P1. With a logical ALT, the trace of communication will be <c1,c2>, whereby the logical ALT determines the sequence of this trace. By looking at the urgencies of the client processes we would expect that process P1 should be served (read) before process P2, because P1 has more important things to do. The logical ALT starts with checking the first guard and therefore chooses the first guard, because both inputs were ready. The logical ALT will check the second guard first at the second run, this time P1 will be served, but then this can be too late for P1 to meet its deadline.
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 85 The desired trace of communication should be <c2,c1>, whereby P1 is served before P2. Remember that P1 has a higher priority than P2. This sequence should be forced by the PRIPAR and not by the prioritized selection mechanism of the ALT. The preference ALT is exactly doing this. The preference ALT will determine the priority order of its guards based on the priority of the client processes under a PRIPAR. With preference alting, the trace will be <c2,c1>. Client processes with the same priority, i.e., under a PAR, will be treated as a logical ALT as in example 8a. Note that the ALT has the lowest priority and after reading an input, the associated writing client process will immediately preempt the alting process. Thus, the guarded processes P or Q will be executed when P1 and P2 are waiting for some event or when they both have terminated successfully. This issue will be discussed more in depth in section 3.3. 3.1.4 PRIALTing in the presence of a PRIPAR Example 8d (see previous page) illustrates a PRIALTing process communicating with two client processes with different priorities. With a logical PRIALT, the trace of communication will be <c1,c2>. This is not an optimal trace, because P1 has a higher priority than P2 and therefore P1 should be served before P2. A preference PRIALT will adapt its decision to the urgency of its surrounding client processes and therefore the trace of communication will be <c2,c1>. Thus, the sequence of the trace is primarily forced by the PRIPAR and not by the selection mechanism of the PRIALT. This is the optimal trace that is desired. Remarkably, a (logical) PRIALT is known as an unfair ALT, but the preference PRIALT adapts its behavior to the priorities of the surrounding client processes and becomes fair! 3.2 Preference alting implementation. In this section we discuss the implementation mechanism of precedence alting. Both the preference ALT and preference PRIALT are based on the same mechanism. The differences between these ALTs are that the ALT assigns equal priorities to its guards and the PRIALT assigns declining priorities to its guards as they were logical ALTs. The idea is that the client processes willing to communicate with the alting process will be queued in a prioritized order. If processes have equal priority then they will be mutually ordered according to the priorities of the guards. The basic idea is the same as for multiple writers that are communicating with a single reader on a shared channel. A data-flow model is given in figure 1a. P1 P2 P1 = P2 P1 > P2 = = > > P4 P4 P4 P3 P3 P3 Figure 1a, b, and c: alting on a share channel. The processes P1, P2, P3 and P4 are running in parallel. All processes will rendezvous on the shared channel. The reader (P4) that is willing to read from the channel will be blocked until a writer sends a value on the channel. A writer (P1, P2, or P3) that is willing to write on the channel will be blocked until the reader is committed to communication. A writer that is willing to communicate on the channel must also be blocked when another writer has claimed (i.e., the first process that is waiting for the reader) the channel. The writer that claims the channel will
86 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority release the channel when it performs communication with the reader. The writer that was next waiting will claim the channel. Blocking writers will be queued by the channel, as illustrated in figure 1b. If the writers have the same priority then they will be queued in a first-come-firstserved (FCFS) order. The equal priority relations between the writers are illustrated in figure 1b. The sorting of the queue depends on the priorities of the processes. For example, in example 1c, the processes P1, P2 and P3 have different priorities. Writer P1 has the highest priority, writer P3 has the lowest priority, and the priority of the writer P2 is somewhere in the middle. The priority of reader P4 is not considered in this example. The sorting algorithm will store the process in order of priority whereby the highest priority of all other processes on the queue will be stored in front of the queue. Thus, if process P3 is the first process waiting on the queue for the reader and when P1 comes along, then process P1 will take the place of P3 and P3 will be the next element in the queue. Thus, a channel will be released in priority order. The reader will serve P1 first because it has the highest priority of all other waiting processes. The shared channel will always adapt to any change in priority of its client processes. This mechanism is similar to a generalized guarded alternative construction known as a prefix choice in CSP. The prefix choice is defined as?x : A P(x) assuming that A Σ is any set of events, for each x A, and P(x) is a process then this defines a process which accepts any element x of A and the behaves like the appropriate P(x). This is a general guarded alterative construction, since any guarded alternative can be recast in this form [14] (the reverse is not true for A is infinite). In case of a channel we can define the prefix choice as?c.x : A P(x) with c.x representing a communication event consisting of a channel c and a message x. Set A is the type of the channel then the set {c.x x A) will be the set of events with c. The process c.x P(x) can be considered as output c!x P(x) or as input c?x P(x). The reader process P4 in our shared channel example is such an alternative process. We can define P4 as c.x :A 1 A 4 P(x) c.y :A 2 A 4 P(y) c.z :A 3 A 4 P(z) where P i is allowed to communicate in the set A i, which is called its alphabet. Process P 1 and P 4 must cooperate on, A 1 A 4, and so on. This can be translated to the form x A c.x P(x) with A = (A 1 A 4 ) (A 2 A 4 ) (A 3 A 4 ). Clearly, this is a prefix choice (or alting) process for a shared channel. The form for multiple channels is defined as x A i I c i.x P(x) where i is in some finite indexed set I. The prefix choice decision for a shared channel or multiple channels is similar except one or multiple channels are involved. The external choice has a similar form but selects one out of multiple guarded processes as defined as
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 87 x A i I c i.x P i (x) When P i = P j with i, j I and i j then this form is equal to the prefix choice with multiple channels. Important is that the decisions made by these processes are based on the same principles of a shared channel. This means that the priorities of the client processes should play an important role in its decision. Therefore, the preference alting process uses the same ideas as in figure 1. The alternative construction that is preformed by the alting process has a special queuing mechanism that sorts each element on the alting queue by priority of processes and by priority of its guards. If the client processes have different priorities then queuing is similar as with a shared channel, as in figure 1c, but if they have equal priorities then they will be mutually ordered according to the priorities of the guards. In CTJ we store the guards instead of the client processes for optimization reasons. The alting queue is a linked-list of guards. Each guard can be chained to other guards in the queue and easily be added, removed or moved. Also, each guard in the queue has a reference to its client process. So, the alting queuing mechanism can easily retrieve the priorities of the client processes and the priorities of the guards to order the guards in the queue. P1 P2 P3 a b c choice run run run P4 P5 P6 Figure 2: alting process. Figure 2 illustrates an alting process of three guarded processes communicating with three client processes. The choice mechanism is basically based on a queuing mechanism as found for the shared channel example in figure 1. An important difference between the shared channel approach and the ALT is that the queuing mechanism of the shared channel is permanent operational and the queuing mechanism of the ALT is volatile operational only when the ALT is executing or is waiting. This means that the FCFS queuing mechanism is only performing when the ALT is executing or is waiting. On the termination of the ALT, i.e., the CTJ implementation will not release the waiting guards but they will stay on the alting queue for the next run. This holds the FCFS principle for multiple runs.
88 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority import csp.lang.*; import csp.lang.process; import csp.util.buildingblocks.recursive; public class Examples { /** The main entry point for the application. **/ public static void main (String[] args) { //--- Lets declare the channels final Channel_of_Any a = new Channel_of_Any(); final Channel_of_Any b = new Channel_of_Any(); final Channel_of_Any c = new Channel_of_Any(); final Channel_of_Any d = new Channel_of_Any(); //--- Lets construct the process composition Process process = new Parallel(new Process[] { // (*) new Process() { public void run() { System.out.println("Process 1: writing to channel d."); d.write();, new Process() { public void run() { System.out.println("Process 2: writing to channel c."); c.write();, new Process() { public void run() { System.out.println("Process 3: writing to channel b."); b.write();, new Process() { public void run() { System.out.println("Process 4: writing to channel a."); a.write();, new Recursive( new Alternative(new Guard[] { new Guard((ChannelInput)a, new Process() { public void run() { System.out.println("Guard 1: reading channel a."); a.read(); ), new PriAlternative(new Guard[] { new Guard((ChannelInput)c, new Process() { public void run() { System.out.println("Guard 2: reading channel c."); c.read(); ), new Guard((ChannelInput)d, new Process() { public void run() { System.out.println("Guard 3: reading channel d."); d.read(); ) ), new Guard((ChannelInput)b, new Process() { public void run() { System.out.println("Guard 4: reading channel b."); b.read(); ) ), 4) ); //--- Lets run the process composition process.run(); Example 9: CTJ listing.
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 89 CHAN OF ANY a,b,c,d CHAN OF ANY a,b,c,d CHAN OF ANY a,b,c,d CHAN OF ANY a,b,c,d PAR d!any c!any b!any a!any ALT i=0 FOR 4 a?any PRIALT c?any d?any b?any PAR ALT i=0 FOR 4 a?any PRIALT c?any d?any b?any d!any c!any b!any a!any PRIPAR d!any c!any b!any a!any ALT i=0 FOR 4 a?any PRIALT c?any d?any b?any PRIPAR ALT i=0 FOR 4 a?any PRIALT c?any d?any b?any d!any c!any b!any a!any Example 10: (a) PAR-CLP-ALT, (b) PAR-ALT-CLP, (c) PRIPAR-CLP-ALT, and (d) PRIPAR-ALT-CLP examples. The ALT will mark each channel that is part of a guard to be an alting channel. It is the alting channel that will add or remove the associated guards on the alting queue, not the ALT itself. If a client process writes on the alting channel then the channel write-operation will add the associated guard to the alting queue. On communication with a guarded process then the readoperation will remove the guard from the alting queue. This is the reverse for output guards. The choice mechanism will sort and read the highest priority guard from the alting queue and execute the associated guarded process that will read or write on the alting channel. On termination of the ALT, each alting channel will be set back to be a normal channel. That s basically all. We would like to explain the alting mechanism here in more detail as being implemented in CTJ, but this not easily to do in one or two pages, plus the code may undergo some minor changes. Furthermore, the source code is free available at the CTJ web site [4]. At the surface the code is much more stable and therefore we will illustrate the CTJ alternative constructs by two simple examples. Example 10a illustrates a PAR construct with a nested alternative construct and four client processes communicating on channels a, b, c and d. The alternative construct reads all the four channels recursively before it terminates. The CTJ code of this example is given in example 9. Although the CTJ example requires more code (more detailed) its transformation from occam to Java is straightforward. The output of example 9 is given in example 11a. As mentioned before, the alting queue is performing when the ALT is executing or is waiting. Although channel d was first ready it is channel a that was selected first by the ALT. Here, the ALT operates as a logical ALT. It is different when we move the recursive ALT before the client processes, as illustrated in example 10b. (Hence, PAR-ALT-CLP). In this case, the ALT will be waiting for the client processes trying to communicate. Example 11b shows the output of this configuration. Example 9 can be modified by moving the Recursive process before the client processes. Example 10c illustrates a PRIPAR construct that assigns different priorities to its processes. We can change the PAR to PRIPAR in the Java code of example 9 by changing line (*) in Process process = new PriParallel(new Process[] { The output of example 10c is given in example 11c. As in example 10b we can move the ALT before the client processes as illustrated in example 10d. Be aware that the ALT has the highest priority. The output is given in example 11d and one can notice a preemptive behavior between the guarded processes and the client processes.
90 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority Process 1: writing to channel d. Process 2: writing to channel c. Process 3: writing to channel b. Process 4: writing to channel a. Guard 1: reading channel a. Guard 2: reading channel c. Guard 3: reading channel d. Guard 4: reading channel b. Process 1: writing to channel d. Process 2: writing to channel c. Process 3: writing to channel b. Process 4: writing to channel a. Guard 2: reading channel c. Guard 3: reading channel d. Guard 4: reading channel b. Guard 1: reading channel a. Process 1: writing to channel d. Process 2: writing to channel c. Process 3: writing to channel b. Process 4: writing to channel a. Guard 3: reading channel d. Guard 2: reading channel c. Guard 4: reading channel b. Guard 1: reading channel a. Process 1: writing to channel d. Guard 3: reading channel d. Process 2: writing to channel c. Guard 2: reading channel c. Process 3: writing to channel b. Guard 4: reading channel b. Process 4: writing to channel a. Guard 1: reading channel a. Example 11: (a) PAR-CLP-ALT, (b) PAR-ALT-CLP, (c) PRIPAR-CLP-ALT, and (d) PRIPAR-ALT-CLP outputs. In case a dynamic scheduling algorithm is used for the PRIPAR, the behavior of the ALTs automatically adapts to every new situation. In circumstances whereby the priority of client processes changes dynamically, while some guards are already on the alting queue, the selection may not be adequate in that case the ordering of guards may become unfair. It is necessary to reorder alting queues on every change in process priorities. In a nested alting construct not every alting queue has to be reordered; only the path of alting queues with the selected guard needs to be reordered. 3.3 Efficiency and output guards The mechanism of the preference ALTs, as previously described, supports input-guards, outputguards, timeout-guards, skip-guards and nested ALTs. Timeout-guards and skip-guards are not discussed in this paper. The implementation of this mechanism is reasonably efficient. Each PRIALT holds an alting queue and therefore the length of sorting for each alting queue is relatively short. The worst case of the sorting algorithm, whereby all elements in the queue must be checked before being added to the queue, is the same worse case for the algorithm of the logical ALT. Moving elements in the queue as a result of sorting, adding guards to the queues and removing guards from the queue are the additional overheads compared to the algorithm of the logical ALTs. These queue manipulations are just a few pointer assignments for each sorting step. Modern processors with fast memory-cache and parallel pipelining can do this sorting efficiently. The fairness that can be achieved by preference alting could have greater effects on efficiency than the latency of sorting. This effect should be studied when optimizing the implementation of the preference ALTs in software or in hardware. More research is to be done here. Abandoning output guards because of implementation difficulties and efficiency reasons is no longer a good argument. Eliminating output guards by applying the workaround, as suggested by Jones, calls for extra channel communication and performs extra unnecessary context switches. Furthermore, the workaround is a source for extra priority inversion when the alting process has a lower priority than a client process. For instance, example 6 is a workaround of example 2 may suffer from double priority inversions. The client process that is willing to communicate with the alting process via chan3 must wait until the alting process is executing. If the client process has preempted another process with a priority between the client process and the alting process, then the client process must wait for this process before the alting process can do the alting. This efficiency problem is called priority inversion. After communication on chan3 the alting process will be preempted and the client process can continue. This is illustrated in example 12. If in the meantime a process with a priority in the middle has become active then another priority inversion arises on communication with chan2. Special measures must be taken twice to solve the priority inversion problem.
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 91 PRIPAR SEQ -- client process chan3!request chan2?object -- perform process P P() other processes -- processes with intermediate priority ALT -- alting process chan3?request -- possible priority inversion you may do nothing here chan2!object -- possible priority inversion Q(object) Example 12: extra priority inversion with workaround. Thus, the extra channel chan2 causes extra inefficiency in case of priority inversion. The use of output guards reduces this extra source of priority inversion. See example 13: PRIPAR SEQ -- client process chan2?request -- perform process P P() other processes -- processes with intermediate priority ALT -- alting process chan2!object -- possible priority inversion Q(object) Example 13: priority inversion with alting. As discussed in Hilderink [5] the use of priority inheritance is an implicit solution that is hard to realize with channels. We belief, priority inheritance is a hack and not a natural solution. A priority inversion problem should be recognized and dealt with at design level. With CTJ and JCSP one can add a buffer to channels. By using a channel with a one-place buffer for chan2, one can overcome the problem of priority inversion. It should be noticed that the output guard is always ready when the buffer is empty. It is a simple and effective solution. 4. Semantics of Alting This section discusses the definitions of alting as previously mentioned. We start with describing the definition of the ALT as found in the theory of CSP. Then we give á definition of the PRIALT in the same manner as the ALT, but with a prioritized decision. Then, in particular, the definitions of logical and preference alting are described and some properties are given. For the logical ALTs and preference ALTs we introduce some new symbols to distinguish the different operators. 4.1 Definitions Two processes maybe composed to form a new process using the external choice operator. It has the general form P Q
92 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority The operator is defined in the following manner: (x:a P(x)) (y:b Q(y)) = def z:c R(z) where R(z) = P(z) if z ΠA - B = Q(z) if z ΠB - A = P(z) Q(z) if z ΠA B If the first event offered by P and Q are disjoint, the new process behaves according to ordinary choice, otherwise according to the internal choice operator that is characterized by the fact that the environment cannot influence the choice between the processes P(z) and Q(z). The process P(z) Q(z) behaves either as P(z) or as Q(z). The choice between them is made internally and, therefore, it is not possible to predict which one of the process P(z) and Q(z) may emerge from P(z) Q(z). The operators and are idempotent (P P=P, P P=P), commutative (P Q=Q P, P Q=Q P) and associative ((P Q) R=P (Q R), (P Q) R=P (Q R)). Two processes maybe composed to form a new process using the external prioritized choice operator. It has the general form P Q The operator is defined in the following manner: (x:a P(x)) (y:b Q(y)) = def z:c R(z) where R(z) = P(z) if z ΠA - B = Q(z) if z ΠB - A = P(z) if z ΠA B The definitions of the operators and apply for purely concurrent processes, whereby each process on parallel hardware. As illustrated in section 3, we think that the definitions are not optimal for concurrent processes in a deterministic environment, particularly, when client processes have different priorities. The non-deterministic behavior of process P(z) Q(z) is impossible to realize on a deterministic processor. To distinguish between theoretical choices and realistic choices, i.e., their implementations, we shall introduce the logical choice operators and which are the corresponding deterministic versions of the theoretical choice operators and. The choice operators and are the occam versions of the ALT and PRIALT.
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 93 The operator is defined in the following manner: (x:a P(x)) (y:b Q(y)) = def z:c R(z) where R(z) = P(z) and i=1 if z Œ A - B = Q(z) and i=0 if z Œ B A = with i ŒZ and i is initially 0. if ( i=0) then Pz ( ) if ( i=1) then Qz ( ) i = ( i+1) modulo 2 if z Œ A B The fair alternative as described by Roscoe to express a fair by using is also a valid solution. The definition of is similar as the definition of. The preference choices will be denoted by the new operators and. In order to describe the definitions of and we must know the priorities of the client processes that are committed in communication with the alting process. If we refer to the priority of a process we mean implicitly the priority of the thread of control that is executing that process. That is, a process has no knowledge about its priority. The function pri(a) returns the priority value of the executing thread of the (client) process that is firstly committed to communication event a, which is defined as pri(a) = { a.thread.priority a.thread.priority N; a.thread THREAD; a S with THREAD as the non-empty set of all threads and S as the set of all events. A priority relation between events of a choice construct whereby their client processes have equal priorities is defined as { pri(a) = pri(b) (a.thread.priority = b.thread.priority Ÿ a.thread π b.thread Ÿ a π b) (a=b) with a A and b B. A priority relation between events whereby their client processes have different priorities is defined as { pri(a) > pri(b) a.thread.priority < b.thread.priority Ÿ a.thread π b.thread Ÿ a π b The occurrence times t a and t b of the events a and b in a deterministic environment can never be the same, so, here t a π t b. The operator is defined in the following manner: (x:a P(x)) (y:b Q(y)) = def z:c R(z)
94 G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority where R(z) = P(z) if z ΠA - B = Q(z) if z ΠB - A = P(z) if z ΠA B and pri(x) > pri(y) = Q(z) if z ΠA B and pri(x) < pri(y) = P(z) if z ΠA B and pri(x) = pri(y) and t a < t b = Q(z) if z ΠA B and pri(x) = pri(y) and t a > t b The operator is defined in the following manner: (x:a P(x)) def (y:b Q(y)) = z:c R(z) where R(z) = P(z) if z ΠA - B 4.2 Properties of alting = Q(z) if z ΠB - A = P(z) if z ΠA B and pri(x) > pri(y) = Q(z) if z ΠA B and pri(x) < pri(y) = P(z) if z ΠA B and pri(x) = pri(y) In this section we will give some properties of alting for the operators,,,, and. On the basis of these properties we can observe any constructive parallels. As mentioned in the previous section, the operator is idempotent, commutative and associative. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) = ( b B)( a A ) <commutative> ( ) ( ) ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associ ative> Operator is idempotent and associative, but not commutative. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) ( b B)( a A ) <not commutative> ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associative> ( ) ( )
G.H.Hilderink and J.F.Broenink / Conditional Communication in the presence of priority 95 Operator is idempotent, associative and partially commutative. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) ( b B)( a A ) <partially commutative> ( ) ( ) ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associative> Operator is partially commutative. If both events a and b are ready then ( a A)( b B ) will initially select process ( a A ) and ( b B)( a A ) will initially select ( b B ), assuming that the left process is the first in the list of guards and the right process is the second in the list of guards under the alternative construct. This is because by the fact that i is always initially 0. At multiple runs the alternations of both left-side and right-side processes seem to be statistically equal. Operator is idempotent and associative, but not commutative. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) ( b B)( a A ) <not commutative> ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associative> ( ) ( ) Operator is not commutative. If both events a and b are ready then the left-side process will be selected, assuming that the left process is the first in the list of guards and the right process is the second in the list of guards under the alternative construct. Operator is idempotent, commutative and associative, equally to the operator. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) = ( b B)( a A ) <commutative> ( ) ( ) ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associative> Operator is idempotent, associative and partially commutative. ( a A)( a A) = ( a A ) <idempotent> ( a A)( b B) = ( b B)( a A) pri( a) pri( b ) <commutative> { {( )( ) ( )( ) ( ) = ( ) ( ) ( ) a A b B b B a A pri a pri b <not commutative> ( a A) ( b B)( c C) = ( a A)( b B) ( c C ) <associative> If pri(a) = pri(b) then the preference choice operator shows similarities with the logical choice operators: