Scalable Multi-core Model Checking: Technology ...resources.mpi-inf.mpg.de/departments/rg1/conferences/vtsa14/slides/... · Scalable Multi-core Model Checking: Technology & Applications

Scalable Multi-core Model Checking:Technology & Applications of Brute Force

part II: Liveness & Timed Systems

UNIVERSITY OF TWENTE. Formal Methods & Tools.

Jaco van de Pol30, 31 October 2014

VTSA 2014, Luxembourg

... Multi-core LTL model checking Interim Evaluation: Exhaustive Brute Force Timed Automata ...

Table of Contents

1 Multi-core LTL model checkingBuchi automata for LTL model checkingNested Depth First SearchParallel Nested Depth First Search

2 Interim Evaluation: Exhaustive Brute Force

3 Timed Automata: subsumption of symbolic statesTimed Buchi automata and subsumptionMulti-core Implementation of ReachabilityLTL model checking with subsumption

UNIVERSITY OF TWENTE. Multi-core Model Checking 30, 31 October 2014 2 / 45


Recall LTL

LTL formulae are built using temporal operators

φ and ψ are formulae, interpreted over infinite paths

I Xφ: φ holds in the next state in this path . . . . . . . . . . . . . neXt

I Fφ: φ holds somewhere in this path . . . . . . . . . . . . . . . . . Future

I Gφ: φ holds everywhere on this path . . . . . . . . . . . . . . . . Global

I φUψ: ψ holds somewhere on this path, and φ holds in allpreceding states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Until

I φRψ: ψ holds as long as φ did not hold before . . . . . Releases

φ ::= p | ¬φ | φ ∧ φ | φ ∨ φ | Xφ | Fφ | Gφ | φUφ | φRφ

Sufficient basis for LTL:

φ ::= p | ¬φ | φ ∧ φ | Xφ | φUφ

φ ∨ ψ = ¬(¬φ ∧ ¬ψ) Gφ = ¬F¬φ φRψ = ¬(¬φU¬ψ)Fφ = true Uφ



Kripke Structures and Paths

Kripke Structures . . . . . . . . . . . . . . . . . . . . . . . . . . (just labeled graphs)

A Kripke structure is a tuple M = (S ,S0,R,AP, L), where

I S is a set of states

I S0 ⊆ S is set of initial states

I R ⊆ S × S is a (total) transition relation on S

I AP is a set of atomic proposition labels

I L : S → P(AP) assigns to each state a set of labels

Infinite Paths . . . . . . . . . . . . . . . (just sequences of connected states)

I A path π in M is an infinite sequence (s0, s1, s2, . . .)through the Kripke structure M, so ∀i . si R si+1

I Notation: π ∈ path(s) if π starts with s (i.e.: s0 = s)

I Notation: πi is the suffix from i , i.e.: (si , si+1, . . .)



Formal CTL* semantics: M , s0 � φ

Semantics of Path Formulas (given path π)

π � φ ⇔ π(0) � φ if φ is a state formulaπ � Xφ ⇔ π1 � φπ � Fφ ⇔ for some i ≥ 0, πi � φπ � Gφ ⇔ for all i ≥ 0, πi � φ

π � φUψ ⇔ ∃i ≥ 0. πi � ψ ∧ ∀j < i . πj � φπ � φRψ ⇔ ∀j ≥ 0.

((∀i < j . πi 6� φ)⇒ πj � ψ

)Some examples of LTL properties

I Every request will be acknowledged: G (req =⇒ reqU ack)

I GF p: p happens infinitely often

I FG p: p is nearly always true

I Note duality: ¬GF p ⇐⇒ FG¬p



Basic Automata Theoretic Approach

Automata Theoretic Approach

I Kripke Structure M (system); LTL formula φ (requirement)

I Construct an automaton A that recognizes violations of φ.

I In other words: A accepts a word π ⇐⇒ π � ¬φI M � φ iff L(M) ⊆ L(φ) iff M × A accepts ∅I Problem: How to deal with infinite words?

Buchi automata for accepting infinite words

I Just like an normal automaton (NFA), with accepting states

I Accept words that hit an accepting state infinitely often



Examples of Buchi automata

almost always: FG p

p

p

¬pinfinitely often: GF p

¬p p

infinitely often with guarantee: G (qU p)

q,¬p

¬q,¬p

p



Model Checking by Accepting Cycles

LTL Model Checking

I A buggy run in a system can be viewed as an infinite wordI Absence of bugs: emptiness of some Buchi automaton

I S ⊆ P iff S ∩ P = ∅ iff S × ¬P has no accepting cycle

I Graph problem: find a reachable accepting state on a cycle

I Basic algorithm: Nested Depth First Search (NDFS)

12

3 4 5

612

5

6

Properties of NDFS

I NDFS runs in linear time

I Inherently depends on post-order

I Post-order is P-complete [Reif’85]

I Not parallelizable (unless P=NC)



Recall: Nested Depth First Search[CVWY’92] [Holzmann’92]

I Blue search: explore graph in DFS orderI states on the blue search stack are cyanI on backtracking from an accepting state:

I Red search: find an accepting cycleI exit as soon as the cyan stack is reached

I Linear time, depends on post-order

Blue search

1: procedure dfsBlue(s)2: add s to Cyan3: for all successors t of s do4: if t 6∈ Blue ∪ Cyan then5: dfsBlue(t)

6: if s is accepting then7: dfsRed(s)

8: move s from Cyan to Blue

Red search

1: procedure dfsRed(s)2: add s to Red3: for all successors t of s do4: if t ∈ Cyan then5: Exit: cycle detected

6: if t 6∈ Red then7: dfsRed(t)



Table of Contents






Simple idea: Swarmed Nested Depth First SearchLaarman, Langerak, van de Pol, Wijs [ATVA’11]

Multi-core Swarmed NDFS

I W workers perform independent random NDFSI Visited states are stored in a shared hashtableI All workers use their own set of colors

(2W bits per state)I Speeds up bug hunting only

Blue search

1: procedure dfsBlue(s, i)2: add s to Cyan[i ]3: for all successors t of s do4: if t 6∈ Blue[i ] ∪ Cyan[i ] then5: dfsBlue(t, i)

6: if s is accepting then7: dfsRed(s, i)

8: move s from Cyan[i ] to Blue[i ]

Red search

1: procedure dfsRed(s, i)2: add s to Red [i ]3: for all successors t of s do4: if t ∈ Cyan[i ] then5: Exit: cycle detected

6: if t 6∈ Red [i ] then7: dfsRed(t, i)



Multi-core Nested Depth First SearchLaarman, van de Pol,...[ATVA’11][PDMC’11]; Evangelista,L,vdP [ATVA’12]

Multi-core NDFS (several variations)

I Collaboration between NDFS workersI Share red and/or blue globallyI Workers backtrack on parts finished by othersI Correctness: Complicated to restore post-orderI Performance: Reasonable scalability

Blue search

1: procedure dfsBlue(s, i)2: add s to Cyan[i ]3: for all successors t of s do4: if t 6∈ Blue ∪ Cyan[i ] then5: dfsBlue(t, i)

6: if s is accepting then7: dfsRed(s, i)

8: move s from Cyan[i ] to Blue

Red search

1: procedure dfsRed(s, i)2: add s to Red3: for all successors t of s do4: if t ∈ Cyan[i ] then5: Exit: cycle detected

6: if t 6∈ Red then7: dfsRed(t, i)



Swarmed NDFS versus Parallel NDFSExperiments from [ATVA’11] on BEEM benchmarks on 16 cores

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'(

()*+',-&#.'

!/"#$%&'(()*+',-&#.'

+,+-./'01'+,+-./','2'3','2'!4'5'3'

Swarmed versusSequential NDFS

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'())*+,(-.'$/(

!"#$%&'(01#))*+,(-.'$/(

+,+-./'01'+,+-./','2'3','2'!%'4'3'

Swarmed versusParallel NDFS

Conclusions

I Swarmed NDFS speeds up bug hunting

I Parallel NDFS also speeds up verification



Table of Contents






Nested Depth First Search [Courcoubetis, Vardi, etal.]

procedure DFSblue(s)s.blue := truefor all t∈ post(s) do

if ¬t.blue then DFSblue(t)if s∈Accepting then

seed := sDFSred(s)

procedure DFSred(s)s.red := truefor all t∈ post(s) do

if t = seed then ExitCycleif ¬t.red then DFSred(t)

Nested DFS

I Blue searchI Visits all reachable statesI Starts Red search on

accepting states (seed)in post order

I Red SearchI Finds cycle through seedI Visits states at most once

I Linear time, on-the-fly

I Blue is inherently depth-first



Swarmed Multi-core Nested Depth First Search

code for worker i

procedure DFSblue(s,i)s.blue[i] := truefor all t∈ post(s) do

if ¬t.blue[i] then DFSblue(t,i)if s∈Accepting then

seed[i] := sDFSred(s,i)

procedure DFSred(s,i)s.red[i] := truefor all t∈ post(s) do

if t = seed[i] then ExitCycleif ¬t.red[i] then DFSred(t,i)

Multi-core Swarmed NDFS

I N workers perform parallelsearch independently

[G. Holzmann etal.]

I Multi-core: store visitedstates in a shared hash table[FMCAD 2010, SPIN 2011]

I Scales well in the presenceof accepting cycles (bugs)

I Otherwise, all workerstraverse the whole graph



Approaches to Parallel LTL Model Checking

Speedup of Swarmed NDFS(1 versus 16 cores)

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'(

()*+',-&#.'

!/"#$%&'(()*+',-&#.'

+,+-./'01'+,+-./','2'3','2'!4'5'3'

[BEEM database]

Alternatives

I Swarm verification with NDFSI Effective, only for bug finding

I Dual-core NDFS [Holzmann]I Red search on 2nd CPUI Speedup of at most factor 2

I Red Search as parallel reachabilityI Speedup still ≤ 2: |G |+ |G |/N

I Can one do better?I Post-order is P-Complete, soI DFS not efficiently parallelizable

I Breadth-first based:I OWCTY, MAP [Brno]I Not linear (|G | · h), not on-the-fly



New NDFS with Cyan and Pink [a la Schwoon/Esparza]

s.bc: white → cyan → blues.rc: white → pink → red

procedure DFSblue(s)s.bc := cyanfor all t ∈ post(s) do

if t.bc=white then DFSblue(t)if s ∈ Acc then DFSred(s)s.bc := blue

procedure DFSred(s)s.rc := pinkfor all t ∈ post(s) do

if t.bc=cyan then ExitCycleif t.rc=white then DFSred(t)

s.rc := red

0

1

2

3

4

5

6

7

8



What goes wrong if the DFS order is violated?

0

1

2

3 4

1

2

3 4

1

2

3 4

What if:

I Red search starts from 1, noCyan state is encountered

I On the backtrack, the statesare colored red

I A new red search starts from2, but terminatesimmediately

No accepting cycle is detected!



Parallel NDFS: share the red color (first try)

s.color[i] : white → cyan → blues.pink[i], s.red : Boolean

procedure DFSblue(s,i) pruned by shared red colors.color[i] := cyanfor all t ∈ post(s) do

if t.color[i]=white and ¬t.red then DFSblue(t,i)if s ∈ Acc then DFSred(s,i)s.color[i] := blue

procedure DFSred(s,i) pruned by shared red colors.pink[i] := truefor all t ∈ post(s) do

if t.color[i]=cyan then ExitCycleif ¬t.pink[i] and ¬t.red then DFSred(t,i)

s.red := true (unfortunately incorrect)



Example: what is the meaning of red? (2 workers)

All accepting cycles contain red:

12

3 4 5

12

3 4 5543

2

3 4 55

6

Accepting states on cycles get red:

12

3 4 5

6

No problem: path pink→cyan

12

3 4 5

6



Synchronisation is necessary: third worker strikes!

0

1

7

43 5

Workers 1,2 proceed as before

0

1

7

43 5

0

7

Worker 3 starts Red search in 1, 0No cycle will be detected!



Parallel NDFS: share the red color (correct version)

procedure DFSblue(s,i)s.color[i] := cyanfor all t ∈ post(s) do

if t.color[i]=white and ¬t.red then DFSblue(t,i)if s ∈ Acc then DFSred(s,i)s.color[i] := blue

procedure DFSred(s,i)s.pink[i] := truefor all t ∈ post(s) do

if t.color[i]=cyan then ExitCycleif ¬t.pink[i] and ¬t.red then DFSred(t,i)

pink[i] := falseif s ∈ Acc then await ∀j : ¬s.pink[j]s.red := true [ATVA 2011]



Optimization 1: Early detection and 2N+1+log(N) bits

procedure DFSblue(s,i)s.color[i] := cyanfor all t ∈ post(s) do

if t.color[i]=cyan and s or t ∈ Acc then ExitCycleif t.color[i]=white and ¬t.red then DFSblue(t,i)

if s ∈ Acc then s.count++; DFSred(s,i)s.color[i] := blue

procedure DFSred(s,i)s.color[i] := pinkfor all t ∈ post(s) do

if t.color[i]=cyan then ExitCycleif t.color[i] 6=pink and ¬t.red then DFSred(t,i)

if s ∈ Acc then s.count−−; await s.count=0s.red := true



Optimization 2: Sprinkle red paint [Gaiser/Schwoon]

procedure DFSblue(s,i)s.color[i] := cyanall successors red := truefor all t ∈ post(s) do

if t.color[i]=cyan and s or t ∈ Acc then ExitCycleif t.color[i]=white and ¬t.red then DFSblue(t,i)if ¬t.red then all successors red := false

if all successors red then s.red := trueelse if s ∈ Acc then s.count++; DFSred(s,i)s.color[i] := blue

procedure DFSred(s,i)s.color[i] := pinkfor all t ∈ post(s) do

if t.color[i]=cyan then ExitCycleif t.color[i] 6=pink and ¬t.red then DFSred(t,i)

if s ∈ Acc then s.count−−; await s.count=0s.red := true


1

2 3

4

3

1


Swarmed NDFS versus Parallel NDFS

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'(

()*+',-&#.'

!/"#$%&'(()*+',-&#.'

+,+-./'01'+,+-./','2'3','2'!4'5'3'

Swarmed NDFS(1 versus 16-core)

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!!"#$%&'

%()*+,%

-./!!"#$%&'0%()*+1,%

+,+-./'01'+,+-./','2'3','2'!4'5'3'

Parallel NDFS(1 versus 16-core)



OWCTY and Swarmed NDFS versus Parallel NDFS

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#(%*'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'())*+,(-.'$/(

!"#$%&'(01#))*+,(-.'$/(

+,+-./'01'+,+-./','2'3','2'!%'4'3'

Swarmed versus Parallel NDFS(both 16 cores)

!"#$%&'

!"#$%!'

!"#(%%'

!"#(%!'

!"#(%&'

!"#(%)'

!"#$%&' !"#$%!' !"#(%%' !"#(%!' !"#(%&' !"#(%)' !"#(%*'

!"#$%&'()*+,)

-.*

/(01'$2(

!"#$%&'(3.#445+6(01'$2(

+,+-./'

01'+,+-./'

2'3','

2'3'!%'4','

2'3'!5!%'4','

OWCTY versus Parallel NDFS(both 16 cores)



Experiments extended to 48 coresFrom [PDMC’12]. See fmt.cs.utwente.nl/tools/ltsmin/performance/

Reachability

0

10

20

30

40

● ●● ● ● ● ●

0 10 20 30 40 50Threads

Spe

edup

Legend

● divine−table

ltsmin−cleary−tree

ltsmin−table

ltsmin−tree

spin−hc

spin−nohc

Promela: Bakery protocol

LTL model checking

0

10

20

30

40

● ● ● ● ● ● ●

0 10 20 30 40 50Threads

Spe

edup

Legend

● divine−owcty

ltsmin−cndfs

spin−pb

Promela: Elevator controllor


fmt.cs.utwente.nl/tools/ltsmin/performance/


Table of Contents






Interim Evaluation: what did we learn?

Reachability: Implementation matters, keep it simple

I Leave workers alone when possible; load balancing

I Rely on randomness to avoid “duplicate work”

I Careful design of concurrent data structures

LTL model checking

I Previous parallel algorithms (OWCTY) used BFS: O(N2)I Now: linear, speedups . . .P = NC , or what did we do?

I W →∞ versus W = 48I Worst case O(N ·W ), no speedup

Remaining theoretical questions

I Average (randomized) runtime/scalability analysis

I Why doesn’t this work for Strongly Connected Components?



Practical Evaluation: Solved multi-core model checking?

Multi-core MC is compatible

I On-the-fly

I Partial-order reduction

I State compression

I Symbolic model checking

Quite general

I Arbitrary state/edge labels

I mCRL2, Promela, DVE, GSPN,

I LLVM, C, xUML, POOSL, ??

I Domain Specific Languages?

Remaining Questions

I Even better speedup – especially for symbolic model checking

I Quite restricted to explicit state model checking

I Infinite state systems? data, recursion, time, BDDs, . . .



Table of Contents






Model checking LTL for Timed AutomataLaarman, Olesen, Dalsgaard, Kim Larsen, vdPol [FORMATS’12] [CAV’13]

Handling Timed Automata

I Work with timed zones (DBM) for Timed Buchi AutomataI Checking LTL properties for Uppaal timed automata

I Use subsumption to prune Nested DFS where possibleI Multi-core NDFS algorithm for Timed Buchi Automata

Tool support

propertyDBMlibrary

resultverification

mc−NDFSLTSmin

C++ codesuccessoropaal

xml−file generator

ltl2ba

Uppaal

LTL

I Open source through opaal and LTSminI opaal-modelchecker.com/I fmt.cs.utwente.nl/tools/ltsmin/


opaal-modelchecker.com/

fmt.cs.utwente.nl/tools/ltsmin/


Table of Contents






Timed Buchi Automata [Alur,Dill’94]

`0 `1 `2

y ≤ 2 y ≤ 2

x := 0, y := 0

y := 0

[x > 2] x := 0, y := 0

Ingredients

I locations (`0, `1, `2), can be initial or accepting

I transitions, governed by real-valued clocks (x , y)

I timed runs should respect clock guards, resets, invariants

`0,

(00

)2.7−→ `0,

(00

)1.8−→ `1,

(1.80

)0.5−→ `2,

(00

)2.0−→ `1,

(2.02.0

)6→

Question: is the Buchi language empty? . . . . . . . no counterexample

Does a (non-zeno) timed run exist that visits an accepting state infinitely often?



Finite representation: zone abstraction, extrapolation

`0 `1 `2

y ≤ 2 y ≤ 2

y := 0

[x > 2] x := 0, y := 0x := 0, y := 0

Finite representation by zones (DBM) [Dill’89] [Daws,Tripakis’98]

I A zone is a set of constraintsI finite by taking into account the lower/upperbounds

`0,Z0 `1,Z1 `2,Z2

`1,Z2

wNo accepting run!

Z0 := y = xZ1 := y ≤ x ∧ y ≤ 2Z2 := y = x ∧ y ≤ 2

Subsumption:Z2 ⊆ Z1, so (`1,Z2) v (`1,Z1)



Subsumption, or inclusion abstraction

Why explore a state again, if it is subsumed by a previous state?

s0 s1

s2 s3

w

Zone abstraction

s0

s2

s3

s1

s3 v s1

s0 s1

s2

subsumption

Known results [Behrmann et al’04] [Tripakis’09] [Li’09]

I finite zone abstraction preserves reachability of locations

I finite zone abstraction also preserve Buchi emptiness

I subsumption preserves reachability of locations as well

Open problem posed in [Tripakis’09]

Is emptiness of Timed Buchi Automata preserved by subsumption? NO



Table of Contents






Extension to Multi-core Reachability . . . [FORMATS’12]

I Timed zones captured in Difference Bound Matrices (DBM)

I For LTSmin, extend discrete state vector swith a pointer to a DBM (s, σ)

I Extend the PINS API with a function Covers(σ, τ)

I Hash based on discrete parts, keep list of maximal zones

I Can be generalized to other symbolic domains(lattice model checking)



Table of Contents






Analysis of accepting spirals with subsumption [CAV’13]

v is a simulation relation:

s ′

s t

v

→

t ′→v

v is a finite abstraction

s’ t’

t’’

s t

t’’’

Lemma: If s has an accepting cycle then any s ′ w s has it as wellLemma: If t ′ has an accepting spiral then t ′ has an accepting cycle

Preservation of accepting cycles Proof Sketch

s ′

s t t

v

→∗ →+

t ′ t ′′→∗ →+

v v

· · · · · ·· · · x · · ·

· · · · · ·

t ′′′

t

→+ →+

→+ →+

v

x

t

→+

→+

v



Subsumption in Nested Depth First Search [CAV’13]

Blue search find accepting states in post order

1: procedure dfsBlue(s)2: Cyan := Cyan ∪ {s}3: for all successors t of s do4: if t 6∈ Blue ∪ Cyan∧ t 6v Red then Prune the blue search5: dfsBlue(t)

6: if s is accepting then7: dfsRed(s)

8: Blue,Cyan := Blue ∪ {s},Cyan\{s}

Red search find cycles on accepting states

1: procedure dfsRed(s) Postcondition: no accepting spiral reachable2: Red := Red ∪ {s}3: for all successors t of s do4: if t ∈ Cyan t w Cyan then Accepting spiral found!5: Exit: cycle detected

6: if t 6∈ Red t 6v Red then Spiral on t would give spiral from Red7: dfsRed(t)



Subsumption on Blue is Unsound

Assume we would backtrack on t as soon as t v Blue:s0s0

s1s1

s ′1s′1

s2s2

s ′2s′2

s4s4

s3s3s3

s5s5

Accepting cycle s4–s5 not detected

I The blue search proceeds via s0, s1, s2, then backtracks via s1 to s3

I Now since s ′2 v Blue, the blue search is pruned at s3

I s3 ∈ Acc, so a red search is started: s3, s ′2, s ′1, s4, s5

I The only accepting cycle s4–s5 is erroneously made red

I Note: accepting states are not visited in post-order



Experiments: speedup up to 48 coresReachability: [Formats’12]. LTL model checking: [CAV’13]

BFS Reachability on Timed Automata

0

10

20

30

40

●●●

●

●

●

●

● ●●

0 10 20 30 40 50Threads

Spe

edup

Model

● fischer6

train−crossing−stdred−5

train−gate−N10

train−gate−N9

viking15

viking17

Checking LTL on Timed Automata

0

10

20

30

40

50

●

●

●

●

●

●●

●

0 10 20 30 40 50Threads

Spe

edup

Model

● csma

fddi

fischer−1

fischer−2

train−gate

Experiments with opaal and LTSmin – open sourcehours −→ minutes −→ seconds



Literature on LTSmin (liveness - LTL model checking)

LTL model checking

I Alfons Laarman, Rom Langerak, Jaco vd Pol, Michael Weber, A. Wijs,Multi-Core Nested Depth-First Search. . . . . . . . . . . . . . . . . . . . (ATVA 2011)

I Alfons Laarman, Jaco van de Pol,Variations on Multi-Core Nested Depth-First Search . . . . . . (PDMC 2011)

I Sami Evangelista, Alfons Laarman, Laure Petrucci and Jaco van de Pol,Improved Multi-Core Nested Depth-First Search . . . . . . . . . . .(ATVA 2012)

Timed Automata

I A. Dalsgaard, A.W. Laarman, K.G. Larsen, M. Olesen, J. van de Pol,Multi-Core Reachability for Timed Automata . . . . . . . . . . . (FORMATS’12)

I Alfons Laarman, M. Olesen, A. Dalsgaard, K.G. Larsen, J. van de Pol,Multi-core emptiness checking of timed Buchi automata using inclusionabstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (CAV’13)


Documents

Scalable Multi-core Model Checking: Technology ...resources.mpi-inf.mpg.de/departments/rg1/conferences/vtsa14/slides/... · Scalable Multi-core Model Checking: Technology & Applications