You are on page 1of 30

Introduction Preliminaries Formal Model Petri Nets Model Checking

Algorithmic Verification of Asynchronous


Programs
Pierre Ganty and Rupak Majumdar, TOPLAS May 2012

Atulya Kumar Verma 1 Mihir Vahanwala 1

1 Indian Institute of Technology, Bombay

Autumn 2021

1/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Outline

Introduction

Preliminaries

Formal Model

Petri Nets

Model Checking

2/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Asynchronous Programming

• A paradigm used to build


• Fast servers and routers
• Embedded systems and sensor networks
• Web programs in Ajax

• Usually, the programmer makes synchronous procedure calls:


caller blocks until callee returns.

• Here, rather than wait for time consuming operations, we can


also make asynchronous procedure calls: these are stored in
a task buffer pending for later execution.

3/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Some Terminology

• Procedures that are asynchronously called by the program are


known as handlers.

• A scheduler picks pending handler instances from the task


buffer and executes them to completion atomically. We call
this a dispatch.
• In this discussion, we disallow non-terminating handler code.

• During execution, a handler can call other handlers, thereby


posting them to the task buffer.

• The interleaving of the dispatches of pending handler


instances hides system latency.

4/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Verification

• We study the algorithmic verification of safety and liveness


of asynchronous programs.

• Safety informally means that “something bad never happens”,


e.g. a web server does not crash

• Liveness means that “something good eventually happens”,


e.g. a request is eventually served, given fairness constraints.

• We create a model of the program and solve for global state


reachability and termination.

• It is known that safety problems reduce to reachability,


liveness problems reduce to termination.

5/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

The Strategy
• The decidability of safety and liveness for synchronous
programs is well known
• The first instinct is to reduce asynchronous programs to
synchronous programs.

• Explicitly model the task buffer as a bunch of (unbounded!)


counters, and increment and decrement on posts and
dispatches.

• While sound, the results don’t go through immediately,


because the system is infinite state.

• The strategy, instead, is to encode asynchronous programs as


Petri Nets, a concurrency model with several decidability
properties, and then use standard algorithms on Petri Nets.
6/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Formal Languages
• An alphabet Σ is a finite non-empty collection of symbols. A
word is a sequence of symbols. Σ∗ denotes the set of finite
words, Σω denotes the set of infinite words.

• A Context Free Grammar (CFG) G is a tuple (X , Σ, P)


where:
• X is a finite set of non-terminal symbols
• Σ is a finite alphabet of terminal symbols
• P is a finite subset of X × (Σ ∪ X )∗

• We say u =⇒ v if there exists a production (X , w ) and


G
y , z ∈ (Σ ∪ X )∗ such that u = yXz and v = ywz.

• Let =⇒∗ denote the reflexive transitive closure of =⇒. Given


G G
X0 ∈ X , the language L = {w : X0 =⇒∗ w } over Σ∗ is said to
G
be context free.
7/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Some Facts

• If every production in the grammar R is from X × (Σ · X ),


then the grammar is called regular, and, given X0 ∈ X , the
language L = {w : X0 =⇒∗ w } over Σ∗ is called a regular
R
language.

• Every CFG can be converted in polynomial time to an


equivalent CFG, where the productions are from

X × (X 2 ∪ Σ ∪ {ε})

• When a start symbol X0 is specified along with a CFG, we


refer to it as an initialized CFG G , and denote the language
it produces by L(G )

8/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Multisets
• A multiset m over an alphabet Σ maps each symbol of Σ to a
natural number. M[Σ] denotes the set of all multisets over Σ.

• If Σ = {q1 , q2 , q3 }, the multiset m = Jq1 , q1 , q3 K denotes the


mapping m(q1 ) = 2, m(q2 ) = 0, m(q3 ) = 1

• Given m, m′ ∈ M[Σ], we define the multiset m ⊕ m′ such that


∀a ∈ Σ, (m ⊕ m′ )(a) = m(a) + m′ (a)

• Define the order ⪯: m ⪯ m′ iff there exists m′′ such that


m′ = m ⊕ m′′

• The Parikh image Parikh : Σ∗ → M[Σ] maps a word w to a


multiset m = Parikh(w ) such that m(a) is the number of
occurrences of a in w . The Parikh image of a language is the
set of Parikh images of words in the language.
9/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Elements of an Asynchronous Program


• A finite set D of global states the program could be in. These
could signify the values held in registers, memory contents,
etc.
• A finite set Σ of handlers.
• Each handler σ has code, which is capable of arbitrarily:
• Recursing
• Manipulating global state
• Posting fresh handler instances

• We model these actions by a CFG G = (X , Σ, P)

• The program is initialised in state d0 and initial task buffer


m0 ∈ M[Σ]. At runtime, the configuration (d, m) ∈ D × M[Σ]
• Thus, we define a program P to be a tuple (D, Σ, G , d0 , m0 )
10/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Handler Code

• When code runs, it does the following, line by line:


• Executes the current instruction, changes the global state and
posts a handler s ∈ Σ ∪ {ε}.
• Jumps to the next instruction, not necessarily sequential, and
possibly in the code of another handler via a synchronous
function call.

• We annotate the code with a set Λ of labels λiσ , for the i th


line in the code for handler σ.
• There is a label after the last instruction of σ, called λend
σ

• We need to define a grammar that


• Respects the above control flow
• Has productions of the form X × (X 2 ∪ Σ ∪ {ε})

11/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

The Grammar

• X : There are two nonterminal symbols corresponding to each


tuple in D × Λ × D. We refer to them as [dλd ′ ] and [dµd ′ ]

• The set of productions P is recursively built as:


• For all σ and d, [dλend
σ d] → ε

• If the instruction at λiσ changes global state from d to d ′ and


posts handler s ∈ Σ ∪ {ε}, then [dµiσ d ′ ] → s

• If there is a jump from λiσ to λiσ′ then there is a production

[dλiσ d ′′ ] → [dµiσ d ′ ][d ′ λiσ′ d ′′ ] for every choice of d, d ′ , d ′′ .

12/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Contexts, Languages and Program Semantics

• Define a context to be an element of D × Σ × D. Let C


denote the set of all contexts.
• Given a context c = (di , σ, df ), let L(G c ) be the language
produced by the CFG G we just constructed, initialised with
the symbol [di λ1σ df ]

Definition (Transition Relation over the set of configurations)


σ
→ (df , m0 ⊕ m) ⇔ m ∈ Parikh(L(G c ))
(di , m0 ⊕ JσK) −

Remark
The handler is dispatched atomically, and we don’t care what order
the new handlers are posted in.

13/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Finite Run Properties

• Safety (Global State Reachability): Given a state df . is a


configuration (d, m) where d = df reachable?

• Task Buffer Boundedness: Is there an N ∈ N such that for


P
all reachable configurations, we have |m| = σ m(σ) ≤ N?

• Configuration Reachability Is the configuration (d, m)


reachable?

14/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Infinite Run Properties

Definition (Fairness)
A run is called fair if finitely many instances of handler σ being
posted implies that there are infinitely many configurations where
there is no pending instance of σ
• (Fair) Non-Termination: Does the program have any (fair)
infinite runs?
• Fair Starvation: Is there a fair infinite run γ0 γ1 . . . γi . . . , a
handler σ and and index J, such that for each j ≥ J,
σ
γj .m(σ) ≥ 1 and if γj =
⇒ γj+1 then γj .m(σ) ≥ 2?

Remark
Fair starvation means that a run could be fair, but a specific
handler instance awaits execution forever. This property is not
desirable.
15/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Semantics
• A Petri Net (PN) N is a triple (S, T , F ) where
• S is a finite non-empty set of places
• T is a finite non-empty set of transitions, and disjoint from S
• F is a pair of functions ⟨I , O⟩, which are maps from T to M[S]
• A marking m ∈ M[S] maps each place p to a non-negative
integer m(p), called the number of tokens at p.
• If I (t) ⪯ m, m[t⟩. The enabled transition can fire, yielding a
new marking m′ such that

m′ ⊕ I (t) = m ⊕ O(t)

We say m[t⟩m′
• Enabledness and firing are inductively extended to sequences
of transitions.

16/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Analogous Problems

• An initialised Petri Net additionally has an initial marking mi .


Define
[mi ⟩ = {m : ∃w ∈ T ∗ . mi [w ⟩m}

• Boundedness: Is [mi ⟩ a finite set? EXPSPACE-complete.

• Reachability: Given arbitrary m, is m ∈ [mi ⟩? Decidable,


EXPSPACE-hard.

17/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Asynchronous Programs as Petri Nets


• We are given a program P = (D, Σ, G , d0 , m0 ). Recall that C
is the set of all contexts, i.e. triples (di , σ, df ).
• For each context, we define a widget: a Petri Net Nc♣
capturing the fact that σ takes di to df . Sc♣ has distinguished
entry and exit places beginc and endc
• If for each c ∈ C

∃w ∈ (Tc♣ )∗ : Jbeginc K[w ⟩(Jendc K ⊕ m) ⇔ m ∈ Parikh(L(G c ))

then N ♣ = {Nc♣ : c ∈ C} is called an adequate family of


widgets.
• Recall that by definition
σ
→ (df , m0 ⊕ m) ⇔ m ∈ Parikh(L(G c ))
(di , m0 ⊕ JσK) −

18/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Stitching Widgets

• We “stitch together” an adequate family of widgets N ♣ to


get an initialised Petri Net NP that models P.

• The places SP = D ∪ Σ ∪ ♣
S
c∈C Sc

• The transitions TP = {tcin , tcout } ∪ Tc♣


S 
c∈C

• FP is such that for each c = (di , σ, df ) ∈ C


• FP (tcin ) = ⟨Jdi , σK, Jbeginc K⟩

• FP (tcout ) = ⟨Jendc K, Jdf K⟩

• For t ∈ Tc♣ , FP (t) = Fc♣ (t)

• The initial marking mi = Jd0 K ⊕ m0

19/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Constructing Adequate Families

• We require that for each c ∈ C

∃w ∈ (Tc♣ )∗ : Jbeginc K[w ⟩(Jendc K ⊕ m) ⇔ m ∈ Parikh(L(G c ))

• The plan, therefore, is to use the widget to simulate the


derivation of a word in L(G c ).

• Idea: Let the non-terminals and the terminal symbols be


places, and the production rules be transitions.

• Issue: On finishing the derivation, i.e. getting a word in Σ∗


we must fire the transition that emits a token to endc . How
do we check that none of the non-terminal places has any
tokens left?

20/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Resolving the Issue

• Let G = (X , Σ, P, X0 ) be an initialised grammar. Let


G G G
X0 =⇒ w1 =⇒ . . . =⇒ wn ∈ Σ∗ be a derivation, wi ∈ (Σ ∪ X )∗
for i < n.

• The derivation is said to be of index k, if, for each i, there


are at most k occurrences of non-terminal symbols in wi .

• Define Lk (G ) ⊆ Σ∗ to be the set of words derivable through


derivations of index k.

Lemma
Let k = |X |. Then Parikh(L(G )) = Parikh(Lk+1 (G ))

21/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

The Construction
• Given c = (di , σ, df ), we consider derivations of bounded index
k + 1, where k = |X |. To this end, in addition to the symbols
in X and σ we use as places, we introduce a “cost place” $c
• Invariant: As the widget simulates the derivation, the total
number of tokens in X ∪ $c is exactly k + 1.
• Sc♣ = X ∪ Σ ∪ {beginc , endc , $c }
• Tc♣ = P ∪ {ti , te }
• Fc♣ is such that
• Fc♣ (ti ) = ⟨Jbeginc K, J[di λ1σ df ], $kc K⟩

• Fc♣ (te ) = ⟨J$k+1


c K, Jendc K⟩
• Fc♣ (X → ε) = ⟨JX K, J$c K⟩

• Fc♣ (X → σ) = ⟨JX K, Jσ, $c K⟩

• Fc♣ (X → Y · Z ) = ⟨JX , $c K, JY , Z K⟩
22/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Safety and Boundedness

Lemma
Let P be an asynchronous program, and let NP be the PN as
constructed in the previous section. We have
• NP can be constructed from P in polynomial time.
• P is bounded iff NP is bounded.
• (d, m) is reachable in P iff JdK ⊕ m is reachable in NP

Our source [1] demonstrates that decision problems on Petri Nets


and asynchronous programs are inter-reducible in poly-time. This
culminates in

23/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Safety and Boundedness - Results

Theorem
• The global state reachability and boundedness problems for
asynchronous programs are EXPSPACE-complete.

• The configuration reachability problem, being poly-time


equivalent to the PN-reachability problem, is
EXPSPACE-hard.

24/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Infinite run properties


Lemma
Let P be an asynchronous program, and let NP be the PN as
constructed in the previous section. We have
• NP can be constructed from P in polynomial time.
• P has a (fair) infinite run iff NP has a (fair) infinite run.
• P fairly starves handler σ iff NP fairly starves σ

1. The decision procedure relies on encoding these properties as


path formulae.
2. Checking satisfiability of these path formulae reduces in
poly-time to reachability on PN, and is hence
EXPSPACE-hard.
3. For some classes of formulae, satisfiability is
EXPSPACE-complete.
25/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Infinite Run Decidability (Yes)

Theorem
• Determining the existence of an infinite run of an
asynchronous program is EXPSPACE-complete.

• Determining the existence of a fair infinite run of an


asynchronous program, and determining the existence of a run
that fairly starves handler σ, being poly-time equivalent to
PN-reachability, are EXPSPACE-hard.
For fair starvation, we will briefly review a slight modification to
the PN construction before we conclude.

26/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Fair Starvation

• Fair Starvation: Is there a fair infinite run γ0 γ1 . . . γi . . . , a


handler σ and and index J, such that for each j ≥ J,
σ
γj .m(σ) ≥ 1 and if γj =
⇒ γj+1 then γj .m(σ) ≥ 2?

• To reason about this, let Cσ ⊂ C be the set of contexts of the


form (d, σ, d ′ )

• The construction enables a guess for J, and treats dispatches


of σ prior and post J slightly differently.

• The adequate family of widgets remains the same, we only


introduce some additional embroidery when we stitch it
together.

27/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Modified Construction
• The places SP = D ∪ Σ ∪ {pf , p∞ } ∪ ♣
S
c∈C Sc

• The transitions TP =
{t f /∞ } ∪ {tcin }c∈C\Cσ ∪ {tcin.f , tcin.∞ }c∈Cσ ∪ c∈C {tcout } ∪ Tc♣
S 

• FP is such that for each c = (di , α, df ) ∈ C


• FP (t f /∞ ) = ⟨Jpf K, Jp∞ K⟩
• FP (tcin ) = ⟨Jdi , αK, Jbeginc K⟩
• FP (tcin.f ) = ⟨Jdi , σ, pf K, Jbeginc , pf K⟩
• FP (tcin.∞ ) = ⟨Jdi , σ, σ, p∞ K, Jbeginc , σ, p∞ K⟩
• FP (tcout ) = ⟨Jendc K, Jdf K⟩
• For t ∈ Tc♣ , FP (t) = Fc♣ (t)

• The initial marking mi = Jd0 , pf K ⊕ m0


28/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Our references

Pierre Ganty and Rupak Majumdar.


Algorithmic verification of asynchronous programs.
TOPLAS, 34(1), May 2012.
doi:10.1145/2160910.2160915.

29/30
Introduction Preliminaries Formal Model Petri Nets Model Checking

Thank you for your attention.

30/30

You might also like