Termination and preemption

The flattening process above described does not completely resolve the problem of the flattening. In fact, according to the well-formedness constraints discussed in Section 4.1.3, each fork is associated with one or more join and furthermore

FIGURE5.4: Flattening for synchronous fork

each box can be associated by zero or more exiting nodes representing the way with which machines can terminate. Thus, the problem of termination should be properly managed since the presence of the dynamic instantiation. Also for the termination issue, Promela does not provide any concept of exiting node neither provides constructs to terminate processes. To guarantee in the mapping pro-cess the termination Promela global channels are exploited. In fact, for each box containing n exiting nodes, n+1 Promela channels are generated and passed as parameters in the run operator. The first n channels are related to the n exiting nodes and are used by the instantiated machines to communicate their termina-tion to the caller machine. The n+1-th internal channel instead, is used by the caller to communicate to its instantiated machines which is terminated. Figures 5.5and5.6represent two different cases of join. In the first case (Figure5.5) two boxes Bx1 and Bx2 are connected to a join pseudonode by the exiting nodes ex11 and ex21. In order to flatten the block represented by the two return by exiting transition T1 and T2, the internal exiting join T3 and the join itself, the transition T 1_T2_T3is generated. Such transition owns a condition that wait for a termina-tion message from both the internal channels associated with the exiting nodes of the boxes. With the respect to the actions, instead, a termination message must be send on the internal channel related to the machine termination.

The second case (Figure5.6), instead, shows a case in which on the same join are connected a node of the current machine (N1) and two boxes. In this case the block is substituted with an internal transition which condition inherits the condition of the internal entering join transition and, as the previous case, the

FIGURE5.5: Flattening of join with only boxes

termination condition of each termination channels of each machines.

FIGURE5.6: Flattening of join with current machine node and boxes

The flattening process is different in case of preemption. DSTM, in fact, en-ables a machine which exit by a preemptive transition to ask for the termination of an instance of each box related to the considered join. In general, in presence of preemptive join, each entering join transition can trigger the termination of all the other parallel machines, regardless of their current state. In this case a distinct internal transition for each preemptive entering join is generated. Each transition inherits the same trigger of the original entering join transition while guards and actions are treated as in the non-premptive case.

With the respect to the preemption several cases are possible which are treated in different ways:

• Case 1: Preemptive transitions with source in a box. When join collects the

exiting state of boxes with a preemptive transition, according to the gen-eral approach described above, the flattening process substitutes the whole block of boxes, internal entering join transitions and internal exiting join tran-sitions with as many trantran-sitions as the preemptive ones. In particular, with the respect to the Figure5.7(a) there are two boxes with a preemptive transi-tions (T1 and T2) and another box with no preemption. The only transition with a trigger is T1. In this case, the substitution is made by means of two transitions: T1_T4 which inherits the trigger of the T1 transition and the ac-tion of T4 with the addiac-tion of terminaac-tion messages on the channel of the other boxes and T2_T4 which has no trigger but the waits condition of the termination of machine M2. Figure5.7(b) depicts the result of the flattening process.

FIGURE5.7: Flattening of preemption in case 1

• Case 2: Asynchronous case with no preemption. In this case on the join insist preemptive transitions with source in boxes and a transition with source in a node of the current machine decorated with triggers and con-ditions. In this case, each preemptive transition, must consider the trigger and the condition since they are related to the execution flow of the current machine. Thus, according to the previous case, the join-block is flattened by adding two transitions: T1_T2_T5 that derives from T2 transition, and inherits trigger and condition from T1 and T1_T4_T5 that inherits from the preemptive transition T4 considering also the trigger of T1. Figure 5.8(b) summarizes the flattening process.

• Case 3: asynchronous case with preemption on current machine. With the

FIGURE5.8: Flattening of preemption in case 2

respect to the previous, this case has the only preemption on the transi-tion which source a node is a node of the current machine. Since the only preemption is related to the execution flow of the current machine, the join-block is substituted by a transition that inherits trigger and condition of the preemptive entering join transition and add in the actions the termination messages for the machines connected to the same join (Figure5.9(b)).

FIGURE5.9: Flattening of preemption in case 3

• Case 4: asynchronous case with preemption on both current and instan-tiated machine. This is the complete case, in which both the current ex-ecution flow and the flows related to the instantiated machine end in the same join with preemptive transitions. Despite the general approach pro-vides a transition for each preemption, in this case, the execution flow of the current machine is priority with the respect to the other flows. Thus, the join block is substituted with a transition that inherits trigger and con-dition from the entering join transition related to the current machine and has as actions the terminations of the other instantiated machines. Figure 5.10exemplifies the flatten model of the above discussed case.

FIGURE5.10: Flattening of preemption in case 4