5.3 A benchmark example: Distributed mutual exclusion algorithm
5.3.1 The STS test set
} }
(a) Program code representation of Fig. 4.4(b)
// Binds r : Resource Iterator<Resource> iR =
getAllResources();
while (iR.hasNext()) { Resource r = iR.next();
// Binds p1 : Process
Process p1 = r.getReleaseTrg();
// Binds p2 : Process
Process p2 = p1.getNextTrg();
// p1, p2, and r now // constitute a matching
}
(b) Program code representation of Fig. 5.1(b)
Listing 5.1: Effects of multiplicity based optimization strategies on the code generated for equivalent search plans
Example 15 Listing 5.2 presents the program code equivalent of the search plan of Fig. 5.2(a).
In this case, pattern nodesRandPhave already been fixed, and their bindings are received by the pattern matching engine as input parameters in matchingm. As a consequence, the engine simply has to check the non-existence of matchings for the negative application condition.
Table 5.2 summarizes the tool support for the presented optimization strategies.
Label+denotes a situation, when a strategy is supported by a given tool, and label–indicates the lack of support for a given optimization method. Since new heuristics can be discovered in the future, this set of tool features cannot be complete, but it already includes all widely supported representatives.
5.3 A benchmark example: Distributed mutual exclusion algorithm
I propose to select a distributed mutual exclusion algorithm as a benchmark example for the scenario of simulation of visual languages with dynamic operational semantics. This scenario can be characterized by a nearly static graph structure, where only a small part of the model is modified, and by short rewriting sequences that are executed many times during a simulation. Test sets are defined as rule application sequences that describe different possible runtime behaviours of the system.
The metamodel and the set of graph transformation rules needed to specify this benchmark exam-ple have already been introduced in Sections 3.2.1 and 3.2.2, respectively. For the mutual exclusion algorithm, three test sets have been defined.
5.3.1 The STS test set
This test set can be characterized by smallLHS graphs. The length of transformation sequences, the number of fan-outs and the number of matchings are parameter dependent, so they are not
distinguish-58 CHAPTER 5. BENCHMARKING FRAMEWORK FOR GRAPH TRANSFORMATION
Forest edge & free node NAC node
Labelling (AGG) Domain reduction (AGG)
P
(b) FUJABA/ReleaseRule P
Figure 5.2: Effects of parameter passing on search plans
1 // Resource r and Process p are specified as inputs in Matching m
2 boolean match(Matching m) {
3 // Copies the value of the shared pattern node p to matching mNAC
4 Matching mNAC = new Matching();
5 mNAC.set(p, m.get(p));
6
7 // Checks NAC
8 if (! nacMatcher.match(mNAC)) {
9 // If no matchings exist for the NAC,
10 // then r and p constitute a matching for the precondition
11 return true;
12 }
13 }
Listing 5.2: Program code equivalent of Fig. 5.2(a)
5.3. A BENCHMARK EXAMPLE: DISTRIBUTED MUTUAL EXCLUSION ALGORITHM 59
Tool features AGG PROGRES FUJABA DB
parameter passing + + + +
0..1 multiplicities - + +
-parallel execution - + + +
as long as possible - - -
-Table 5.2: Tool support for optimization strategies
ing features of this test set.
Initial instance models only contain two processes and two links of typenextconnecting the pro-cesses in both directions (as presented in Fig. 5.3(a)). The test set has one parameterN, which denotes the maximum number of processes appearing in the instance model during a specific run.
p1:Process p2:Process
(b) Model after the 1st step
p1:Process p2:Process
(c) Model after the 2nd step
p1:Process p2:Process
(d) Model after the 3rd step
p1:Process p2:Process
(e) Model after the first loop execution
p1:Process p2:Process
(f) Model after the 4th step
Figure 5.3: Models in different phases of the STS test set whenN = 4
The transformation sequence can be described as follows.
(a) NewRule (Fig. 3.5(a)) is applied first N–2 times in an arbitrary order. Since each application ofNewRule adds a process to the token ring, after this step the instance model has a ring
struc-60 CHAPTER 5. BENCHMARKING FRAMEWORK FOR GRAPH TRANSFORMATION
ture consisting of exactly N processes that are connected byN links of typenextas shown in Fig. 5.3(b).
(b) The second step is to create a single resource by performing theMountRule (Fig. 3.5(c)) once.
This rule also gives access rights to one of the processes, which is modeled by a newly created
tokenlink. The instance model is shown in Fig. 5.3(c).
(c) In the third step, each process issues arequestfor the single resource, which means the execution of RequestRule(Fig. 3.5(f)) for N times. Regardless of the execution order, the final instance model will be the one that is presented in Fig. 5.3(d). (So it is possible to applyRequestRulein parallel.)
(d) The final step handles the requests that have been issued in the previous step. To handle a single requestTakeRule,ReleaseRuleandGiveRulehave to be applied in this specific order. In order to speed up pattern matching, parameter passing is possible among the rules that belong to the same loop.
TakeRule (Fig. 3.5(g)) assigns the process with the token to the resource by creating a held by
link. Then ReleaseRule (Fig. 3.5(h)) lets the resource to be released by the process. Finally, the resource is released and the token is propagated to the next process in the token ring by the execution ofGiveRule(Fig. 3.5(i)). The instance model at this point is shown in Fig. 5.3(e).
Since all theN processes have already requested the resource, the above-mentioned 3 rules have to be executed in a loop forN times, which results in a rule execution sequence of length 3N. (Note that there exists only a single matching to which the subsequent rule can be applied at the time when the rule application is scheduled, so the rule execution order of the fourth step is fully deterministic.) In the end, the instance model will be the one that is depicted in Fig. 5.3(f).
The transformation sequence consists of 5N–1 rule applications altogether. The largest instance model that appears during the rule application phase hasN+1 objects and 2N+1 links (see Fig. 5.3(d)).
Optimization possibilities.
• Instead of having zero-to-many multiplicities on all association ends, it is possible to restrict some of them to zero-to-one, as it is presented in the metamodel of Fig. 3.4(a). Since the model contains only a single resource, knowing and using this fact may cause performance improve-ments for some tools, since pattern matching can be started at this well-defined node.
• As it was already mentioned in the test set description, the three rules in the loop of the fourth step may be applied in such a way that the selected processes and resources can be passed to consecutive rules as input parameters, which may speed-up pattern matching.