We have discussed so far the abstraction refinement procedure based on the notion of cycle dependencies that are actually mutual inclusion relations among cycles imposed by condition statements. As mentioned previously, there are other types of dependencies among cycles which are caused by graphic structures of control flow graphs. Examples were given in the end of Section 10.2, includ-ing Example 10.3. In this section we consider the discovery of graph structure imposed dependencies and the use of such information to refine abstractions.
Unlike previously, the analysis described in this section can be performed at the level of CFSM systems since we are only interested in the graphic charac-teristics and CFSM systems preserve the structures of their original Promela models. Based on reasons similar to the argument in Section 12.1, the refine-ment methods described in this section apply only to the livelock freedom test.
Given a counterexample in which two cycles in one same process do not share common states, some other cycles in the same process have to be included in the counterexample to “bridge” them. We introduce the concept of self-connected cycle sets.
Definition 12.2 (Self-Connected Cycle Sets). A set of control flow cycles in a CFSM process is self-connected if and only if these cycles form a strongly connected subgraph of the state machine of the process.
A counterexample is spurious if, for some process p, the set of cycles fromp in the counterexample is not self-connected.
We propose the following refinement. Given a counterexample, suppose that there are two cyclesc1 andc2 from one same processpin the counterexample such that they are not reachable from each other by traversing through only the cycles in the counterexample. We determine all the self-connected sets of cycles of pthat contain both c1 and c2. If no such set exists, then c1 and c2
belong to different strongly connected components. This implies thatc1 andc2
mutually exclude each other. Therefore, there are three possible cases: (1)c1 is executed infinitely often whilec2is not; (2)c2is executed infinitely often while c1 is not; and (3) both cycle are not executed infinitely often. Let x1 and x2
be the variables corresponding respectively toc1 andc2in the livelock freedom determination ILP problems. The above possibilities can be expressed as three sets of linear inequalities
x1>0 (12.44)
x2= 0 (12.45)
and
x1= 0 (12.46)
x2>0 (12.47)
and
x1= 0 (12.48)
x2= 0 (12.49)
The sets above triplicates the number of livelock freedom determination ILP problems as each ILP problem can only be augmented with one of the three sets.
Alternatively, suppose that there exists at least one self-connected set of cycles containing bothc1 andc2. Letn denote the number of determined self-connected cycle sets. Then, there arendifferent ways to “connect” the cycles c1 andc2. For each determined self-connected setS, we can generate a set of linear inequalities as below, assuming that eachxiis the variable corresponding toci in the livelock freedom determination ILP problem
^
ci∈S
xi>0 (12.50)
Besides, we also have the three possibilities as expressed respectively in Inequal-ities (12.44–12.49). In this way, we obtainn+ 3 sets of linear inequalities. Each set will be used to modify the livelock freedom determination ILP problems in the same way as previously explained.
Example 12.5.Consider the state machine in Figure 12.4. All the self-connected cycle sets containingc1andc2areS1={c1, c2, c3, c4}andS2={c1, c2, c5}. Let xi be the variable corresponding to the cycleciin the livelock freedom determi-nation problems. Then, we generate the following sets of linear inequalities
x1>0 (12.51)
x2>0 (12.52)
x3>0 (12.53)
x4>0 (12.54)
and
x1>0 (12.55)
x2>0 (12.56)
x5>0 (12.57)
and
x1>0 (12.58)
x2= 0 (12.59)
and
x1= 0 (12.60)
x2>0 (12.61)
and
x1= 0 (12.62)
x2= 0 (12.63)
0
Figure 12.4: The state machine of a CFSM process.
A caveat of the above described method is that the number of newly gen-erated ILP problems can grow exponentially, since the number of determined self-connected sets for two cycles can be exponential in the size of the respective process. As a solution, we propose an alternative method that only generates 4 sets of linear inequalities instead of n+ 3 sets. Consider the state machine in Figure 12.4. To reachc2 from c1, one of the neighbors of c1 must be entered.
Similarly, one of the neighbors of c2 must be entered in order to reachc1 from c2. Based on this observation, we can generate only one set of linear inequalities to restrict the behavior in which both cycles are repeated infinitely often, given as follows
x1>0 (12.64)
x2>0 (12.65)
x3+x5>0 (12.66)
x4+c5>0 (12.67)
To generalize this idea we assume that two cyclescandc′ from some processp in a counterexample are not reachable from each other by traversing only the cycles in the counterexample. We compute a sequence of pairs of cycle sets:
h(Nc0, Nc0′), . . . ,(Ncn, Ncn′)i where (1) Nc0 is the set of neighbors of c, (2) Nci+1 contains all cycles that neighbor some cycle in Nci and that are not in anyNcj ifj ≤i, and (3) Nci′ is defined likewise. We terminate the computation of the sequence for some numbernsuch that either (1)NcnorNcn′ is empty, or (2) there are a cycle inNcn and a cycle inNcn′ such that these two cycles are neighbors. If the first termination condition is true, thencandc′must be in different strongly connected components. The treatment in this case is the same as in the previous refinement method. If the second termination condition is true, then we know that one cycle from each set in the sequence hNc0, . . . , Ncn, Nc1′, . . . , Ncn′i has to be entered when traveling between c and c′. This can be expressed using the following set of inequalities, assuming that the variable x corresponds to c, x′ corresponds to c′, and each xj corresponds to cj in the livelock freedom
determination ILP problems
Consider the state machine in Figure 12.5. Let xi be the variable corre-sponding to the cycleci in the livelock freedom determination ILP problems. If a counterexample containsc1 andc2 but no other cycles in the state machine, then the counterexample is spurious. Furthermore, we can obtain the following set of linear inequalities to restrict the behavior in which both c1 and c2 are repeated infinitely often
x1>0 (12.72)
x2>0 (12.73)
x3+x5>0 (12.74)
x4+x6>0 (12.75)
However, this constraint cannot exclude a potentially spurious counterexample that containsc1,c2,c3, andc6.
Figure 12.5: The state machine of a CFSM process
Summary We have proposed in this chapter several methods to refine ab-stractions based on discovering cycle dependencies. Some methods may increase exponentially the number of ILP problems for the determination of livelock free-dom. A practical strategy of abstraction refinements is therefore to apply the refinement methods based on graph structure only when the abstract system cannot be refined anymore by the methods based on cycle dependencies. Fi-nally, note that any linear inequality constructed in the refinement procedure is homogeneous such that any boundedness or livelock freedom determination ILP problem augmented with this inequality is still homogeneous and can be solved in polynomial time. The efficiency and effectiveness of our abstraction refine-ment procedure will be evaluated using case studies as described in Chapter 14.
Implementations and Experiments
175
Verification Tools
In the previous chapters we have presented the foundation and the technical details of our verification framework and its applications to the checking of the buffer boundedness and livelock freedom properties. We have implemented the verification methods for these two properties into two prototype tools: IBOC, a boundedness checker; andaLive, a livelock freedom checker. In this chapter we present the tool architecture and discuss some specific issues related to the implementation of these tools, such as cycle detections.
IBOC. The buffer boundedness test explained in Chapter 5 has been im-plemented in the IMCOS Boundedness Checker or, in short, IBOC. IBOC can check boundedness for both Promela models and UML RT models. When it suc-cessfully proves boundedness for a model without going through the refinement procedure, it also delivers an estimated bound for each buffer in the model.
The code abstraction of Promela models is fully automated in IBOC, except that the actually running processes of a model must be manually determined for the time being. Manual abstraction is currently required as a preprocessing step for UML RT models. IBOC accepts only UML RT models in which the action code of transitions contains nothing more than a sequence of message sending statements. Moreover, the refinement procedure is only implemented for Promela models.
aLive. The livelock freedom test explained in Chapter 6 has been implemented in the aLive tool. Currently, aLive checks livelock freedom only for Promela models. Users can define their set of progress actions in a model by adding progress labels in front of the proper Promela statements in the model. In the Promela language, a label is a progress label if it has the prefixprogress.
Structure. In Section 13.1 we show the common software architecture of the IBOC and aLive tools. Section 13.2 addresses the problem of enumerating elementary cycles in a control flow graph. Section 13.3 checks the feasibility to reduce the number of effect vectors used to construct ILP problems for the sake of efficiency. Finally, a refinement strategy for buffer bound estimation is suggested in Section 13.4.
177
13.1 Tool Architecture
As explained in the previous chapters, the buffer boundedness and the livelock freedom tests share the common abstraction techniques, the ILP solving tech-niques, and the refinement techniques. As a consequence, the IBOC and aLive tools may reuse the same modules for abstractions, ILP solving, refinement, and also cycle enumerations.
Promela models UML RT models
Manual code abstraction
Automated code abstraction
Effect vector Generation
cycle detection
ILP encoding w.r.t. boundedness
ILP encoding w.r.t.
livelock freedom
ILP solver
Counterexample construction
Detecting cycle dependencies
IBOC aLive
ILP encoding w.r.t.
bound estimation
Figure 13.1: The common software architecture of IBOC and aLive.
Figure 13.1 shows the common software architecture of IBOC and aLive.
The only difference in the implementations of the two tools is the different ILP encodings needed for the analysis of the respective property. Arrows denote data flow between different modules. We briefly explain the functionality of each module in the figure.
Automated code abstraction. This module can only abstract Promela models for the time being. UML RT models need manual abstraction of tran-sition action code as a preprocessing step. The code abstraction of Promela models is detailed in Chapter 7. The output of this module is a CFSM system.
In this step, message types are also determined for Promela models.
Effect vector generation. For the CFSM system generated by code abstrac-tion, the message passing effect is computed for each transition. The output of this module is essentially a VASS system, although for reasons of efficiency this is not explicitly constructed.
Cycle enumeration. Control flow cycles are enumerated in this module and the summery effect vector is also calculated for each cycle. The output of this module is an independent cycle system. In IBOC the least upper bound on acyclic path effects is also computed along with the the detection of cycles. As shown in the next section, for efficiency reasons aLive may use a different cycle enumeration algorithm. However, in our implementation the same algorithm in Listing 13.1 is used in both IBOC and aLive. With this step the abstraction is completed.
ILP encoding. From the effect vectors in the independent cycle system, an ILP problem is constructed in this module for the checking of the property.
IBOC and aLive use different ILP encodings as explained in Chapter 5 and Chapter 6, respectively. This module also translates the cycle dependencies discovered in the refinement procedure into linear inequalities, and refine the property checking ILP problems with these inequalities.
ILP solver. We currently use an open source linear optimization tool named lp solve[5] for the solving of ILP problems. It uses a variant of the simplex algorithm to solve linear programming problems, and the combinatorial Branch-and-Bound algorithm to solve ILP problems. lp solvedoes not take advantage of the polynomial solving method for homogeneous ILP problems as described in Section 5.7.2. However, we observed that it worked still efficiently in practice as the experimental results suggested in Chapter 14.
Counterexample construction. If the ILP solver returns a solution to a property checking ILP problem, then it indicates a potential violation of the checked property. This module finds all the control flow cycles in the original Promela model such that these cycles correspond to those cycles in the indepen-dent cycle system whose variables receive non-zero values in the returned ILP solution. The found cycles form a counterexample that will be subject to the cycle dependency analysis in the refinement procedure.
Detecting cycle dependencies. This module checks each cycle in the con-structed counterexample for the discovery of cycle dependencies. For each cycle c, it tries to determine three sets of cycles that c may depend on: (1) neigh-boring cycles (see Corollary 11.5 in Section 11); (2) local supplementary cycles (see Listing 11.5); and (3) the cycles sending the types of messages thatcneeds (see Section 11.4). The first two kinds of dependencies are caused by locally determined conditions. Therefore, the discovery of them requires termination proving and cycle iteration times estimation that were implemented based on the idea in Section 12.2. The third kind of dependencies is caused by message determined conditions, whose discovery is detailed in Section 11.4. This module
currently does not support the discovery of dependencies caused by globally de-termined conditions. However, it can be easily implemented and we will include it in the future development of the IBOC and aLive tools.