On-the-Fly Model Checking for Extended Action-Based Probabilistic Operators

Abstract

The quantitative analysis of concurrent systems requires expressive and user-friendly property languages combining temporal, data-handling, and quantitative aspects. In this paper, we aim at facilitating the quantitative analysis of systems modeled as PTSs (Probabilistic Transition Systems) labeled by actions containing data values and probabilities. We propose a new regular probabilistic operator that computes the probability measure of a path specified by a generalized regular formula involving arbitrary computations on data values. This operator, which subsumes the Until operators of PCTL and their action-based counterparts, can provide useful quantitative information about paths having certain (e.g., peak) cost values. We integrated the regular probabilistic operator into MCL (Model Checking Language) and we devised an associated on-the-fly model checking method, based on a combined local resolution of linear and Boolean equation systems. We implemented the method in the EVALUATOR model checker of the CADP toolbox and experimented it on realistic PTSs modeling concurrent systems.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Concurrent systems, which are becoming ubiquitous nowadays, are complex software artifacts involving qualitative aspects (e.g., concurrent behaviour, synchronization, data communication) as well as quantitative aspects (e.g., costs, probabilities, timing information). The rigorous design of such systems based on formal methods and model checking techniques requires versatile temporal logics able to specify properties about qualitative and quantitative aspects in a uniform, user-friendly way. During the past two decades, a wealth of temporal logics dealing with one or several of these aspects were defined and equipped with analysis tools [3, 8]. One of the first logics capturing behavioral, discrete-time, and probabilistic information is PCTL (Probabilistic CTL) [16].

In this paper, we propose a framework for specifying and checking temporal logic properties combining actions, data, probabilities, and discrete-time on PTSs (Probabilistic Transition Systems) [21], which are suitable models for representing value-passing concurrent systems with interleaving semantics. In PTSs, transitions between states are labeled by actions that carry, in addition to probabilistic information, also data values sent between concurrent processes during handshake communication. Our contributions are twofold.

Regarding the specification of properties, we propose a new regular probabilistic operator, which computes the probability measure of a path (specified as a regular formula on actions) in a PTS. Several probabilistic logics have been proposed in the action-based setting. PML (Probabilistic Modal Logic) [21] is a variant of HML with modalities indexed by probabilities, and was introduced as a modal characterization of probabilistic bisimulation. GPL (Generalized Probabilistic Logic) [9] is a probabilistic variant of the alternation-free modal $\mu$-calculus, able to reason about execution trees, and equipped with a model checking algorithm relying on the resolution of non-linear equation systems. Compared to these logics, our probabilistic operator is a natural (action-based) extension of the Until operator of PCTL: besides paths of the form $a^{*} . b$ (the action-based counterpart of Until operators), we consider more general paths, specified by regular formulas similar to those of PDL (Propositional Dynamic Logic) [13]. To handle the data values present on PTS actions, we rely on the regular formulas with counters of MCL (Model Checking Language) [27], which is an extension of first-order $\mu$-calculus with programming language constructs. Moreover, we enhance the MCL regular formulas with a generalized iteration operator parameterized by data values, thus making possible the specification of arbitrarily complex paths in a PTS.

Regarding the evaluation of regular probabilistic formulas on PTSs, we devise an on-the-fly model checking method based on translating the problem into the simultaneous local resolution of a linear equation system (LES) and a Boolean equation system (BES). For probabilistic operators containing dataless MCL regular formulas, the sizes of the LES and BES are linear (resp. exponential) w.r.t. the size of the regular formula, depending whether it is deterministic or not. In the action-based setting, the determinism of formulas is essential for a sound translation of the verification problem to a LES. For general data handling MCL regular formulas, the termination of the model checking procedure is guaranteed for a large class of formulas (e.g., counting, bounded iteration, aggregation of values, computation of costs over paths, etc.) and the sizes of the equation systems depend on the data parameters occurring in formulas. It is worth noticing that on-the-fly verification algorithms for PCTL were proposed only recently [22], all previous implementations, e.g., in PRISM [19] having focused on global algorithms. Our method provides on-the-fly verification for PCTL and its action-based variant PACTL, and also for PPDL (Probabilistic PDL) [18], which are subsumed by the regular probabilistic operator of MCL. We implemented the method in the EVALUATOR [27] on-the-fly model checker of the CADP toolbox [15] and experimented it on various examples of value-passing concurrent systems.

The paper is organized as follows. Section 2 defines the dataless regular probabilistic operator and Sect. 3 presents the on-the-fly model checking method. Section 4 is devoted to the data handling extensions. Section 5 briefly describes the implementation of the method within CADP and illustrates it for the quantitative analysis of mutual exclusion protocols. Finally, Sect. 6 gives concluding remarks and directions of future work.

2 Dataless Regular Probabilistic Operator

As interpretation models, we consider PTSs (Probabilistic Transition Systems) [21], in which transitions between states carry both action and probabilistic information. A PTS $M = \langle S, A, T, L, s^i \rangle$ comprises a set of states S, a set of actions A, a transition relation $T \subseteq S \times A \times S$, a probability labeling $L : T \rightarrow (0, 1]$, and an initial state $s^i \in S$. A transition $(s_1, a, s_2) \in T$ (also written $s_1 \mathop {\rightarrow }\limits ^{a} s_2$) indicates that the system can move from state $s_1$ to state $s_2$ by performing action a with probability $L (s_1, a, s_2)$. For each state $s \in S$, the probability sum $\sum _{s \mathop {\rightarrow }\limits ^{a} s'} L (s, a, s') = 1$.

A path $\sigma = s(=s_0) \mathop {\rightarrow }\limits ^{a_0} s_1 \mathop {\rightarrow }\limits ^{a_1} \cdots \mathop {\rightarrow }\limits ^{a_{n-1}} s_n \cdots$ going out of a state s is an infinite sequence of transitions in M. The i-th state and i-th action of a path $\sigma$ are noted $\sigma [i]$ and $\sigma _a[i]$, respectively. An interval $\sigma [i,j]$ with $0 \le i \le j$ is the subsequence $\sigma [i] \mathop {\rightarrow }\limits ^{a_i} \cdots \mathop {\rightarrow }\limits ^{a_{j-1}} \sigma [j]$, which is empty if $i=j$. The suffix starting at the i-th state of a path $\sigma$ is noted $\sigma _i$. The set of paths going out from s is noted $\textit{paths}_M (s)$. The probability measure of a set of paths sharing a common prefix is defined as $\mu _M (\{ \sigma \in \textit{paths}_M (s) \mid \sigma [0,n] = s_0 \mathop {\rightarrow }\limits ^{a_0} \cdots \mathop {\rightarrow }\limits ^{a_{n-1}} s_n \}) = L (s_0, a_0, s_1) \times \cdots \times L (s_{n-1}, a_{n-1}, s_n)$.

The regular probabilistic operator that we propose computes the probability measure of paths characterized by regular formulas. For the dataless version of the operator, we use the regular formulas of PDL (Propositional Dynamic Logic) [13], defined over the action formulas of ACTL (Action-based CTL) [28]. Figure 1 shows the syntax and semantics of the operators.

Action formulas $\alpha$ are built over the set of actions by using standard Boolean connectors. Derived action operators can be defined as usual: $\mathsf{true}= \lnot \mathsf{false}$, $\alpha _1 \wedge \alpha _2 = \lnot (\lnot \alpha _1 \vee \lnot \alpha _2)$, etc. Regular formulas $\beta$ are built from action formulas by using the testing (?), concatenation (.), choice (|), and transitive reflexive closure ($*$) operators. Derived regular operators can be defined as usual: ${\textsf {nil}} = \mathsf{false}^{*}$ is the empty sequence operator, $\beta ^{+} = \beta . \beta ^{*}$ is the transitive closure operator, etc. State formulas $\varphi$ are built from Boolean connectors, the possibility modality ($\langle ~ \rangle$) and the probabilistic operators ($\{ ~ \}_{\ge p}$ and $\{ ~ \}_{> p}$) containing regular formulas. Derived state operators can be defined as usual: $\mathsf{true}= \lnot \mathsf{false}$, $\varphi _1 \wedge \varphi _2 = \lnot (\lnot \varphi _1 \vee \lnot \varphi _2)$, and $\left[ \beta \right] \varphi = \lnot \langle \beta \rangle \lnot \varphi$ is the necessity modality.

Fig. 1.

Modal and probabilistic operators over regular paths

Action formulas are interpreted on the set of actions A in the usual way. A path satisfies a regular formula $\beta$ if it has a prefix belonging to the regular language defined by $\beta$. The testing operator specifies state formulas that must hold in the intermediate states of a path. Boolean connectors on states are defined as usual. A state s satisfies the possibility modality $\langle \beta \rangle \varphi _1$ (resp. the necessity modality $\left[ \beta \right] \varphi _1$) iff some (resp. all) of the paths in $\textit{paths}_M (s)$ have a prefix satisfying $\beta$ and leading to a state satisfying $\varphi _1$. A state s satisfies the probabilistic operator $\{ \beta \}_{\ge p}$ iff the probability measure of the paths in $\textit{paths}_M (s)$ with a prefix satisfying $\beta$ is greater or equal to p (and similarly for the strict version of the operator). A PTS $M = \langle S, A, T, L, s^i \rangle$ satisfies a formula $\varphi$, denoted by $M \, \models \, \varphi$, iff $s^i \, \models _M \, \varphi$ (the subscript $_M$ will be omitted when it is clear from the context).

The operator $\{ \beta \}_{\ge p}$ generalizes naturally the Until operators of classical probabilistic branching-time logics. The Until operator of PCTL [16], and probabilistic versions of the two Until operators of ACTL are expressed as follows:

In addition, regular formulas are strictly more expressive than Until operators, enabling to specify more complex paths in the PTS. For example, the formula:

unexpressible in P(A)CTL due to the nested $*$-operators, specifies that the probability of receiving a message after zero or more retransmissions is at least $90\,\%$.

3 Model Checking Method

We propose below a method for checking a regular probabilistic formula on a PTS on the fly, by reformulating the problem as the simultaneous resolution of a linear equation system (LES) and a Boolean equation system (BES). The method consists of five steps, each one translating the problem into an increasingly concrete intermediate formalism. The first four steps operate syntactically on formulas and their intermediate representations, whereas the fifth step makes use of semantic information contained in the PTS. A detailed formalization of the first four steps, in a state-based setting, can be found in [24]. We illustrate the method by checking the formula $\varPsi _1$ on the PTS of a very simple communication protocol adapted from [3, Chap. 10], shown in Fig. 2(a).

1. Translation to PDL with Recursion. To evaluate an operator $\{ \beta \}_{\ge p}$ on a PTS $M = \langle S, A, T, L, s^i \rangle$ on the fly, one needs to determine the set of paths going out of $s^i$ and satisfying $\beta$, to compute the probability measure of this set, and to compare it with p. For this purpose, it is more appropriate to use an equational representation of $\beta$, namely PDLR (PDL with recursion), which already served for model checking PDL formulas in the non-probabilistic setting [26]. A PDLR specification is a system of fixed point equations having propositional variables $X \in \mathcal{X}$ in their left hand side and PDL formulas $\varphi$ in their right hand side:

where $\varphi _i$ are modal state formulas (see Fig. 1) and $X_1$ is the variable of interest corresponding to the desired property. Since formulas $\varphi _i$ may be open (i.e., contain occurrences of variables $X_j$), their interpretation is defined w.r.t. a propositional context $\delta : \mathcal{X} \rightarrow 2^S$, which assigns state sets to all variables occurring in $\varphi _i$. The interpretation of a PDLR specification is the value of $X_1$ in the least fixed point $\mu \varPhi$ of the functional $\varPhi : (2^S)^n \rightarrow (2^S)^n$ defined by:

where $\left[ \!\left[ \varphi _i \right] \!\right] \delta = \{ s \in S \mid s \, \models _\delta \, \varphi _i\}$, and the interpretation of $\varphi _i$ (see Fig. 1) is extended with the rule $s \, \models _\delta \, X = s \in \delta (X)$. The notation $\delta [U_1/X_1, ..., U_n/X_n]$ stands for the context $\delta$ in which $X_i$ were replaced by $U_i$.

In the sequel, we consider PDLR specifications in $de{{\varvec{r}}}ivative\ {\varvec{n}}ormal\ \varvec{f}\!orm$ (RNF), which are the modal logic counterparts of Brzozowski’s (generalized) derivatives of regular expressions [5]:

where $\varphi _{ij}$ and $\varphi _i$ are closed state formulas. Note that, in the right hand side of equation i, the same variable $X_{ij} \in \{ X_1, ..., X_n \}$ may occur several times in the first disjunct. Intuitively, a variable $X_i$ denotes the set of states from which there exists a path with a prefix satisfying some of the regular formulas $\beta _{ij}$ and whose last state satisfies $X_{ij}$. This is formalized using path predicates $P_i : \textit{paths}_M \rightarrow \textsf {bool}$, defined by the following system of equations:

More precisely, $(\mu \varPhi )_i = \{ s \in S \mid \exists \sigma \in \textit{paths}_M (s) . P_i (\sigma ) \}$.

The PDLR specification in RNF associated to a formula $\beta$ is defined below:

in which the variable of interest $X_1$ denotes the PDL formula $\langle \beta \rangle \mathsf{true}$, expressing the existence of a path with a prefix satisfying $\beta$ and leading to some final state denoted by $X_2$. The corresponding path predicates are:

According to the interpretation of regular formulas (see Fig. 1), the path predicate $P_1 (\sigma )$ holds iff $\sigma \, \models \, \beta$, and also $(\mu \varPhi )_1 = \{ s \in S \mid \exists \sigma \in \textit{paths}_M (s) . \sigma \, \models \, \beta \}$.

2. Translation to HML with Recursion. To bring the PDLR specification closer to an equation system suitable for verification, one must simplify it by removing the regular operators occurring in modalities. This yields a HMLR (HML with recursion) specification [20], which contains only HML modalities on action formulas. Regular operators can be eliminated by applying the following substitutions, which are valid equalities in PDL [13]:

The rules for the ‘.’ and ‘*’ operators create new equations, necessary for maintaining the PDLR specification in RNF (the insertion of $\langle {\textsf {nil}} \rangle X$ modalities, which are equivalent to X, serves the same purpose). The rule for the ‘|’ operator creates two occurrences of the same variable X, reflecting that a same state can be reached by two different paths. These rules preserve the path predicates $P_i$ associated to the PDLR specification, and in particular $P_1 (\sigma )$, which specifies that a path $\sigma$ satisfies the initial formula $\beta$.

The size of the resulting HMLR specification (number of variables and operators) is linear w.r.t. the size of $\beta$ (number of operators and action formulas). Besides pure HML modalities, the HMLR specification may also contain occurrences of $\langle {\textsf {nil}} \rangle X$ modalities, which will be eliminated in the next step.

3. Transformation to Guarded Form. The right hand side of an equation i of the HMLR specification may contain modalities of the form $\langle \alpha _{ij} \rangle Y_{ij}$ and $\langle {\textsf {nil}} \rangle Y_{ij}$ (equivalent to $Y_{ij}$), which correspond to guarded and unguarded occurrences of variables $Y_{ij}$, respectively. To facilitate the formulation of the verification problem in terms of equation systems, it is useful to remove unguarded occurrences of variables. The general procedure for transforming arbitrary $\mu$-calculus formulas to guarded form [17] can be specialized for HMLR specifications by applying the following actions for each equation i: (a) Remove the unguarded occurrences of $X_i$ in the right hand side of the equation by replacing them with false, which amounts to apply the $\mu$-calculus equality $\mu X . (X \vee \varphi ) = \mu X . \varphi$. (b) Substitute all unguarded occurrences of $X_i$ in other equations with the right hand side formula of equation i, and rearrange the right hand sides to maintain the equations in RNF. This produces a guarded HMLR specification:

which is the exact modal logic counterpart of Brzozowski’s derivatives of regular expressions [5] defined on the alphabet of action formulas. The transformation to guarded form keeps the same number of equations in the HMLR specification, but may increase the number of operators in the right hand sides.

Fig. 2.

Model checking formula $\psi _1$ on a PTS

4. Determinization. A HMLR specification may contain, in the right hand side of an equation i, several modalities $\langle \alpha _{ij} \rangle X_{ij}$ whose action formulas are not disjoint, i.e., they can match the same action. This denotes a form of nondeterminism, meaning that the same transition $s \mathop {\rightarrow }\limits ^{a} s'$ can start a path $\sigma$ satisfying the path predicate $P_i (\sigma )$ in several ways, corresponding to alternative suffixes of the initial regular formula $\beta$. To ensure a correct translation of the verification problem into a LES, it is necessary to determinize the HMLR specification. This can be done by applying the classical subset construction, yielding a deterministic HMLR specification defined on sets of propositional variables:

where $\textit{alt} (I) = \{ ij \mid i \in I \wedge j \in [1,n_i] \}$. Basically, each alternative $\varphi _{ij} \wedge \langle \alpha _{ij} \rangle X_{ij}$ in an equation $i \in I$ is combined with each alternative in the other equations having their index in I, taking care that the action formulas in the resulting modalities are mutually exclusive. As shown in [24] for a similar construction in the state-based setting, the determinization preserves the path predicate associated to the variables of interest $X_1$ and $X_{\{1\}}$ in the HMLR before and after determinization, i.e., $P_1 (\sigma ) = P_{\{1\}} (\sigma )$ for any path $\sigma \in \textit{paths}_M$.

In the worst case, determinization may yield an exponential increase in the size of the HMLR specification. However, this happens on pathological examples of regular formulas, which rarely occur in practice; most of the time, the nondeterminism contained in a formula $\beta$ is caused by a lack of precision regarding the iteration operators, which can be easily corrected by constraining the action formulas corresponding to iteration “exits”. For example, the regular formula contained in $\varPsi _1$ can be made deterministic by specifying precisely the retries and the fact that they must occur before receptions: ${ send} . ((\lnot { retry} \wedge \lnot { recv})^{*} . { retry})^{*} . { recv}$.

5. Translation to Linear and Boolean Equation Systems. Consider a determinized HMLR specification in RNF corresponding to a regular formula $\beta$:

where $\alpha _{ij} \wedge \alpha _{ik} = \mathsf{false}$ for each $i \in [1,n]$ and $j,k \in [1, n_i]$. The associated path predicates are defined as follows:

They are related to the HMLR specification by $(\mu \varPhi )_i = \{ s \in S \mid \exists \sigma \in \textit{paths}_M (s) . P_i (\sigma ) \}$, and to the initial regular formula $\beta$ by $P_1 (\sigma ) = \sigma \, \models \, \beta$.

The last step of the model checking method reformulates the problem of verifying the determinized HMLR specification on a PTS in terms of solving a LES ($*$) and a BES ($**$) defined as follows:

The LES ($*$) is obtained by a translation similar to the classical one defined originally for PCTL [16]. A numerical variable $Z_{i,s}$ denotes the probability measure of the paths going out of state s and satisfying the path predicate $P_i$. Determinization guarantees that the sum of coefficients in the right-hand side of each equation is at most 1. The BES ($**$) is produced by the classical translation employed for model checking modal $\mu$-calculus formulas on LTSs [2, 10]. A Boolean variable $X_i^s$ is true iff state s satisfies the propositional variable $X_i$ of the HMLR specification. The on-the-fly model checking consists in solving the variable $Z_{1,s^i}$, which denotes the probability measure of the set of paths going out of the initial state $s^i$ of the PTS and satisfying the initial regular formula $\beta$. This is carried out using local LES and BES resolution algorithms, as will be explained in Sect. 5. The conditions $s \, \models \, X_i$ occurring in the LES ($*$) and the conditions $s \, \models \, \varphi _{ij}, s \, \models \, \varphi _i$ occurring in both equation systems are checked by applying the on-the-fly model checking method for solving the variable $X_i^s$ of the BES ($**$) and evaluating the closed state formulas $\varphi _{ij}, \varphi _i$ on state s.

By solving the LES obtained in Fig. 2(f), we obtain $Z_{1,0} = 1.0$, meaning that a message sent will be received (after zero or more retransmissions) with $100\,\%$ probability, and therefore the formula $\varPsi _1$ is true on the PTS.

4 Extension with Data Handling

The regular formulas that we used so far belong to the dataless fragment [26] of MCL, which considers actions simply as names of communication channels. In practice, the analysis of value-passing concurrent systems, whose actions typically consist of channel names and data values, requires the ability to extract and manipulate these elements. For this purpose, MCL [27] provides action predicates extracting and/or matching data values, regular formulas involving data variables, and parameterized fixed point operators. The regular probabilistic operator $\{ \beta \}_{\ge p}$ can be naturally extended with the data handling regular formulas of MCL, which enable to characterize complex paths in a PTS modeling a value-passing concurrent system.

To improve versatility, we extend the regular formulas of MCL with a general iteration operator “loop”, which subsumes the classical regular operators with counters, and can also specify paths having a certain cost calculated from the data values carried by its actions. After briefly recalling the main data handling operators of MCL, we define below the “loop” operator, illustrate its expressiveness, and show how the on-the-fly model checking procedure previously described is generalized to deal with the data handling probabilistic operator.

4.1 Overview of Data Handling MCL Operators

In the PTSs modeling value-passing systems, actions are of the form “$C ~ v_1 \ldots v_n$”, where C is a channel name and $v_1, ..., v_n$ are the data values exchanged during the rendezvous on C. To handle the data contained in actions, MCL provides action predicates of the form “$\{ C ~ ... ~ !e ~ ?x{:}T ~ {\textsf {where}} ~ b \}$”, where “...” is a wildcard matching zero or more data values of an action, e is an expression whose value matches the corresponding data value, x is a data variable of type T that is initialized with the corresponding data value extracted from the action, and b is an optional boolean expression (guard) typically expressing a condition on x. An action predicate may contain several clauses “!e” and “?x : T”, all variables defined by “?x : T” clauses being visible in the guard b and also outside the action predicate. An action satisfies an action predicate if its structure is compatible with the clauses of the predicate, and the guard evaluates to true in the context of the data variables extracted from the action.

Regular formulas in MCL are built over action predicates using the classical operators shown in Sect. 2, as well as constructs inspired from sequential programming languages: conditional (“if-then-else”), counting, iteration (“for” and “loop”, described in the next subsection), and definition of variables (“let”). The testing operator of PDL is expressed in MCL as $\varphi ? = {\textsf {if}} ~ \lnot \varphi ~ \ {\textsf {then}} ~ {\textsf {false}} ~ {\textsf {end}}~{\textsf {if}}$.

Finally, the state formulas of MCL are built using modalities containing regular formulas, parameterized fixed point operators, quantifiers over finite domains, and programming language constructs (“if” and “let”).

4.2 Generalized Iteration on Regular Formulas

The general iteration mechanism that we propose on regular formulas consists of three operators having the following syntax:

The “loop” operator denotes a path made by concatenation of (zero or more) path fragments satisfying $\beta$, each one corresponding to an iteration of the loop with the current value of variable x. Variable x, which is visible inside $\beta$, is initialized with the value of expression $e_0$ at the first loop iteration and can be updated to the value of e by using the operator “${\textsf {continue}}~(e)$”, which starts a new iteration of the loop. The loop is terminated by means of the “${\textsf {exit}}~(e')$” operator, which sets the return variable $x'$, visible outside the “loop” formula, to the value of $e'$.

The iteration and return variables (x and $x'$) are both optional; if they are absent, the “in” keyword is also omitted. For simplicity, we used only one variable x and $x'$, but several variables of each kind are allowed. The arguments of the operators “continue” and “exit” invoked in the loop body $\beta$ must be compatible with the declarations of iteration and return variables, respectively. Every occurrence of “continue” and “exit” refers to the immediately enclosing “loop”, which enforces a specification style similar to structured programming.

For brevity, we define the semantics of the “loop” operator by translating it to plain MCL in the context of an enclosing diamond modality. The translation is parameterized by a profile $Z/x{:}T/x'{:}T'$, where x and $x'$ are the iteration and return data variables of the immediately enclosing “loop”, and Z is a propositional variable associated to it. We show below the translation of the three general iteration operators, the other regular operators being left unchanged.

Basically, a possibility modality enclosing a “loop” operator is translated into a minimal fixed point operator parameterized by the iteration variable(s). The occurrences of “continue” in the body of the loop are translated into invocations of the propositional variable with the corresponding arguments, and the occurrences of “exit” are translated into “let” state formulas defining the return variables and setting them to the corresponding return values.

All iteration operators on MCL regular formulas can be expressed in terms of the “loop” operator, as shown in the table below. For simplicity, we omitted the definitions of $\beta \{ e \}$ (iteration e times) and $\beta \{ ... ~ e \}$ (iteration at most e times), which are equivalent to $\beta \{ e ~ ... ~ e \}$ and $\beta \{ 0 ~ ... ~ e \}$, respectively.

To illustrate the semantics of general iteration, consider the formula $\langle \beta \{ e \} \rangle \mathsf{true}$ stating the existence of a path made of e path fragments satisfying $\beta$. By encoding bounded iteration as a “loop” and applying the translation rules of general iteration, we obtain:

The bounded iteration operators $\beta \{ e \}$, $\beta \{ ... ~ e \}$, and $\beta \{ e_1 ~ ... ~ e_2 \}$ are natural means for counting actions (ticks), and hence describing discrete-time properties. The full Until operator of PCTL, and its action-based counterparts derived from ACTL, can be expressed as follows ($t \ge 0$ is the number of ticks until $\varphi _2$):

Besides counting, the general iteration operators are able to characterize complex paths in a PTS, by collecting the data values (costs) present on actions and using them in arbitrary computations (see the examples in Sect. 5).

4.3 Model Checking Method with Data Handling

The on-the-fly model checking method shown in Sect. 3 can be generalized to deal with the data handling constructs of MCL by adding data parameters to the various equation systems used as intermediate forms. We illustrate the complete method by checking the formula $\varPsi _2$ on the PTS shown on Fig. 2:

Formula $\varPsi _2$, which is a determinized data-based variant of $\varPsi _1$, specifies that the probability of receiving a message after at most n retransmissions (where n is a parameter to be instantiated) is at least $90\,\%$.

The various translation phases are illustrated on Fig. 3. The translation rules for standard regular operators given in Sect. 3 are applied for eliminating the “.” operators in the PDLR specification (Fig. 3(c)). Then, the iteration at most n times is translated into a “loop” operator (Fig. 3(d)), and the corresponding modality is further refined using the semantics of “loop” defined in Sect. 4.2, yielding a HMLR specification parameterized by a counter (Fig. 3(e)). After bringing this specification to guarded form (Fig. 3(f)), a parameterized LES is produced (Fig. 3(g)) by the translation scheme given in Sect. 3, extended to handle data parameters. For instance, variable $Z_{5,1} (v)$ in the LES denotes the probability measure of the paths starting from state $s_1$ and satisfying the path predicate denoted by $X_5$ with the parameter c set to value v.

Fig. 3.

Model checking formula $\psi _2$ on a PTS

Finally, a plain LES is generated (Fig. 3(h)) by instantiating $n = 2$ in the parameterized LES. Note that the guarded HMLR specification was already deterministic (since the regular formula in $\varPsi _2$ was determinized), and hence the LES has a unique solution. By solving this LES (e.g., using substitution), we obtain $Z_{1,0} = 0.999$, which is the probability measure of the paths starting from the initial state $s_0$ of the PTS and satisfying the regular formula specified in $\varPsi _2$. In other words, $n=2$ retransmissions ensure that a message is received with $99.9\,\%$ probability.

Termination. The presence of data parameters (with infinite domains) implies that the whole model checking procedure relies on the termination of the instantiation phase, which must create a finite LES solvable using numerical methods. This is in general undecidable, similarly to the termination of term rewriting [11]. Such situations happen for “pathological” formulas, which carry on divergent computations on data unrelated to the data values contained in the PTS actions. For example, the modality $\langle {\textsf {loop}} ~ (k{:}\textsf {nat}{:=}0) ~ {\textsf {in}} ~ a ~ . ~ {\textsf {continue}} ~ (k+1) ~ {\textsf {end}} ~ {\textsf {loop}} \rangle \mathsf{true}$ will not converge on the PTS consisting of a single loop $s \mathop {\rightarrow }\limits ^{a} s$, since it will entail the construction of an infinite LES $\{ Z_s (0) = Z_s (1), Z_s (1) = Z_s (2), ... \}$. However, the model checking procedure terminates for most practical cases of data handling regular formulas (counting, accumulating or aggregating values, computing costs over paths).

5 Tool Support and Use

In this section, we show how the on-the-fly model checking method for the regular probabilistic operator works in practice. After briefly presenting the implementation of the method within the CADP toolbox [15], we illustrate its application for the quantitative analysis of shared-memory mutual exclusion protocols.

5.1 Implementation

We extended MCL with the general iteration operator “loop” on regular formulas and the regular probabilistic operator $\{ \beta \}_{\bowtie \, p}$, where $\bowtie \; \in \{ <, \le , >, \ge , = \}$. Temporal and probabilistic operators can be freely combined, e.g., $\left[ \beta _1 \right] \{ \beta _2 \}_{\ge p}$ specifies that, from all states reached after a path satisfying $\beta _1$, the probability measure of an outgoing path satisfying $\beta _2$ is at least p.

We also enhanced the EVALUATOR [27] on-the-fly model checker with the translation of $\{ \beta \}_{\bowtie \, p}$ formulas into BESs (for checking the existence of path suffixes) and LESs (for computing probability measures) as described in Sects. 3 and 4. The on-the-fly resolution of BESs is carried out by the algorithms of the CAESAR_SOLVE library [23], which already serves as verification back-end for (non-probabilistic) MCL formulas. For the on-the-fly resolution of LESs, we designed a local algorithm operating on the associated Signal Flow Graphs (SFG) [7], in a way similar to the BES resolution algorithms, which operate on the associated Boolean graphs [2]. The LES resolution algorithm consists of a forward exploration of the SFG to build dependencies between variables, followed by a backward variable elimination (a.k.a. substitution) and a final propagation to update the right-hand sides of equations with the solutions of variables. This substitution method, implemented with a careful bookkeeping of variable dependencies, performs well on the very sparse LESs resulting from $\{ \beta \}_{\bowtie \, p}$ operators (typically, for a PTS with $10^6$ states and a branching factor of 10, there are about $10^{-5} = 0.001\,\%$ non-null elements in the LES matrix). Connections to general purpose solvers for (less sparse) LESs are planned as future work.

5.2 Case Study: Analysis of Mutual Exclusion Protocols

We illustrate the application of the regular probabilistic operator by carrying out a quantitative analysis of several shared-memory mutual exclusion protocols, using their formal descriptions in LNT [6] given in [25]. We focus here on a subset of the 27 protocols studied in [25], namely the CLH, MCS, Burns&Lynch (BL), TAS and TTAS protocols, by considering configurations of $N \le 4$ concurrent processes competing to access the critical section. Each process executes cyclically a sequence of four sections: non critical, entry, critical, and exit. The entry and exit sections represent the algorithm specific to each protocol for demanding and releasing the access to the critical section, respectively. In the PTS models of the protocols, all transitions going out from each state are assumed to have equal probabilities. We formulate four probabilistic properties using MCL and evaluate them on the fly on each LNT protocol description (for MCL formulas consisting of a single $\{ \beta \}_{\bowtie \, p}$ operator, the model checker also yields the probability measure in addition to the Boolean verdict). For each property requiring several invocations of the model checker with different values for the data parameters in the MCL formula, we automate the analysis using SVL scripts [14].

Critical Section. First of all, for each $i \in [0, N-1]$, we compute the probability that process $P_i$ is the first one to enter its critical section. For this purpose, we use the following MCL formula:

which computes the probability that, from the initial state, process $P_i$ accesses its critical section before any (other) process. Symmetric protocols guarantee that this probability is equal to 1 / N for all processes, while asymmetric protocols (such as BL) may favor certain processes w.r.t. the others. This is indeed reflected by the results of model checking the above formula for $N=3$: for the BL protocol, which gives higher priority to processes of lower index, the probabilities computed are $72.59\,\%$ (for $P_0$), $21.66\,\%$ (for $P_1$), and $5.73\,\%$ (for $P_2$), whereas they are equal to $33.33\,\%$ for the other protocols, which are symmetric.

Memory Latency. The analysis of critical section reachability can be refined by taking into account the cost of memory accesses (e.g., read, write, test-and-set operations on shared variables) that a process $P_i$ must perform before entering its critical section. The protocol modeling provided in [25] also considers non-uniform memory accesses, assuming that concurrent processes execute on a cache-coherent multiprocessor architecture. The cost c (or latency) of a memory access depends on the placement of the memory in the hierarchy (local caches, shared RAM, remote disks) and is captured in the PTS by actions “$\mathsf{MU} ~ !c$” [25].

The MCL formula aside computes the probability that a process $P_i$ performs memory accesses of a total cost max before entering its critical section. The regular formula expresses that, after executing its non critical section for the first time, process $P_i$ begins its entry section and, after a number of memory accesses, enters its critical section.

The “loop” subformula denotes the entry section of $P_i$ and requires that it terminates when the cost of all memory accesses performed by $P_i$ (accumulated in the iteration parameter total_cost) exceeds a given value max. The other processes can execute freely during the entry section of $P_i$, in particular they can overtake $P_i$ by accessing their critical sections before it. Figure 4(a) shows the probability of entering the critical section for various values of max. Since the entry section contains waiting loops, the number of memory accesses of $P_i$ before entering its critical section is unbounded (and hence, also the cost max). However, the probability that a process waits indefinitely before entering its critical section tends to zero in long-term runs of starvation-free protocols. This explains the asymptotic probability 1.0 observed in Fig. 4(a): a process has better chances to reach its critical section when the memory cost of its entry section increases.

Overtaking. Even if a mutual exclusion protocol is starvation-free, a process $P_i$ that begins its entry section (and hence, starts requesting the access to the critical section) may be overtaken one or several times by another process $P_j$ that accesses its own critical section before $P_i$ does so. A qualitative measure of a starvation-free protocol is given by its overtaking degree, which is the maximum number of overtakes per couple of processes. This number should be as small as possible, and may vary among process couples for asymmetric protocols. A qualitative study of the overtaking degree was carried out in [25] using MCL regular formulas with counters. Here we use the same property in the probabilistic setting, which enables to compute the probability that process $P_j$ overtakes $P_i$ a given number of times. Figure 4(b) shows the results for the BL protocol, which outline its intrinsic asymmetry: lower index processes, with higher priority, also have better chances to overtake the other processes.

Fig. 4.

Probabilities computed using on-the-fly model checking. (a) Accessing the critical section after memory accesses of cost MAX. (b) Overtaking of $P_i$ by $P_j$ ($P_j\_P_i$) in the BL protocol. (c) Standalone execution of $P_i$.

Standalone Execution. As opposed to overtaking, it is also interesting to examine the dual situation, in which a process $P_i$ executes its cycle in standalone, i.e., without any interference with the other processes. This situation was explicitly formulated in [12] as the independent progress requirement, which should be satisfied by any mutual exclusion protocol. We can analyze this situation by computing the probability measure of a complete execution of process $P_i$ without any other action being performed meanwhile by other processes.

This execution can be specified by the MCL formula aside, where max denotes the number of consecutive executions of $P_i$.

Figure 4(c) shows that the probability of standalone execution of $P_i$ decreases with max, which reflects the starvation-free nature of the protocols.

Performance of Analysis. All model checking experiments have been carried out in a single core of an Intel(R) Xeon(R) E5-2630v3 @2.4 GHz with 128 GBytes of RAM and Linux Debian 7.9 within a cluster of Grid’5000 [4]. The sizes of the PTSs including the additional transitions of memory access costs (available in [25, Table 4]), range from $3\,252$ states and $6\,444$ transitions (for the TAS protocol) to $18\,317\,849$ states and $31\,849\,616$ transitions (for the CLH protocol).

The computing resources needed for on-the-fly verification depend on the complexity of the MCL regular formulas, and in particular the number and domains of their data parameters. For example, the analysis of the first access to the critical section takes between 3.25–5.5 s and 36.5–77 MBytes for all protocol configurations considered. For other properties, such as those concerning the memory latency or the overtaking, some peaks arrive up to 2–3 h and 12–14 GBytes because of the manipulation of data (cost of memory accesses) and iterations (number of overtakes). The analysis of the standalone execution of $P_i$ may take up to 285 s and $1\,230$ MBytes for the BL protocol because of the complex cycles present in the PTS, while the same analysis takes less than 100 s (or even 10 s) for the other protocols.

6 Conclusion and Future Work

We proposed a regular probabilistic operator for computing the probability measure of complex paths in a PTS whose actions contain data values. Paths are specified using the action-based, data handling regular formulas of MCL [27] that we extended with a general iteration operator “loop” enabling the specification of arbitrarily complex paths. These new operators subsume those of P(A)CTL, and make possible the study of paths whose associated cost (calculated from the data values present on their actions) has a given value. We defined an on-the-fly model checking method based on reformulating the problem as the resolution of a linear equation system (LES) and a Boolean equation system (BES), and implemented it in the EVALUATOR model checker of the CADP toolbox.

To assess and finely tune our on-the-fly model checking method, we will experiment it on further examples and compare it (for properties expressible in PCTL) with explicit-state PRISM [19]. The on-the-fly analysis back-end (which is currently sequential) can be enhanced with distributed capabilities by connecting it with the MUMPS distributed solver [1] for sparse LESs. Finally, we will seek to extend our approach (which deals only with finite paths described using data-handling regular formulas) to handle infinite paths satisfying $\omega$-regular properties, along the lines of [3, Chap. 10].