Enforcing Concurrent Temporal Behaviors Doron Peled, Dept. of CS University of Warwick.

Slides:

Advertisements

Similar presentations

1 Verification by Model Checking. 2 Part 1 : Motivation.

Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?

Modeling Software Systems Lecture 2 Book: Chapter 4.

Model Checking and Testing combined

Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.

1 Verification of Parameterized Systems Reducing Model Checking of the Few to the One. E. Allen Emerson, Richard J. Trefler and Thomas Wahl Junaid Surve.

CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.

CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.

Partial Order Reduction: Main Idea

Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.

Knowledge Based Synthesis of Control for Distributed Systems Doron Peled.

Part 3: Safety and liveness

1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.

Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.

Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:

Monitoring Partial Order Snapshots Doron Peled Bar Ilan University, Israel & University of Warwick, UK Joint work with Peter Niebert.

D u k e S y s t e m s Time, clocks, and consistency and the JMM Jeff Chase Duke University.

1 Partial Order Reduction. 2 Basic idea P1P1 P2P2 P3P3 a1a1 a2a2 a3a3 a1a1 a1a1 a2a2 a2a2 a2a2 a2a2 a3a3 a3a3 a3a3 a3a3 a1a1 a1a1 3 independent processes.

NP-complete and NP-hard problems Transitivity of polynomial-time many-one reductions Concept of Completeness and hardness for a complexity class Definition.

1 NP-Complete Problems. 2 We discuss some hard problems:  how hard? (computational complexity)  what makes them hard?  any solutions? Definitions 

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.

CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.

1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.

NP-complete and NP-hard problems Transitivity of polynomial-time many-one reductions Definition of complexity class NP –Nondeterministic computation –Problems.

1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.

Modeling Software Systems Lecture 2 Book: Chapter 4.

NP-complete and NP-hard problems

Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.

Analysis of Algorithms CS 477/677

Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.

Fall 2004COMP 3351 Time Complexity We use a multitape Turing machine We count the number of steps until a string is accepted We use the O(k) notation.

ESE601: Hybrid Systems Introduction to verification Spring 2006.

CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.

272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.

Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.

Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.

MCS 312: NP Completeness and Approximation algorithms Instructor Neelima Gupta

Automatic tests generation for infinite state systems based on verification technology Doron Peled Dept. of Computer Science University of Warwick United.

CS6133 Software Specification and Verification

Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.

Week 10Complexity of Algorithms1 Hard Computational Problems Some computational problems are hard Despite a numerous attempts we do not know any efficient.

NP-COMPLETENESS PRESENTED BY TUSHAR KUMAR J. RITESH BAGGA.

Techniques for Proving NP-Completeness Show that a special case of the problem you are interested in is NP- complete. For example: The problem of finding.

Inferring Synchronization under Limited Observability Martin Vechev, Eran Yahav, Greta Yorsh IBM T.J. Watson Research Center (work in progress)

Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.

NP-COMPLETE PROBLEMS. Admin  Two more assignments…  No office hours on tomorrow.

NP-Complete problems.

CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.

Open Incremental Model Checking (OIMC) and the Role of Contracts Model-Based Programming and Verification.

Reasoning about the Behavior of Semantic Web Services with Concurrent Transaction Logic Presented By Dumitru Roman, Michael Kifer University of Innsbruk,

1 Time Complexity We use a multitape Turing machine We count the number of steps until a string is accepted We use the O(k) notation.

Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.

1 Controlled concurrency Now we start looking at what kind of concurrency we should allow We first look at uncontrolled concurrency and see what happens.

Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.

NOTE: To change the image on this slide, select the picture and delete it. Then click the Pictures icon in the placeholder to insert your own image. Fast.

Model Checking Lecture 1: Specification Tom Henzinger.

Agenda  Quick Review  Finish Introduction  Java Threads.

COSC 3101A - Design and Analysis of Algorithms 14 NP-Completeness.

The NP class. NP-completeness Lecture2. The NP-class The NP class is a class that contains all the problems that can be decided by a Non-Deterministic.

Lecture 5 Page 1 CS 111 Summer 2013 Bounded Buffers A higher level abstraction than shared domains or simple messages But not quite as high level as RPC.

The NP class. NP-completeness

New Characterizations in Turnstile Streams with Applications

Automatic Verification

Faults, Errors, Failures CS 4501 / 6501 Software Testing

TARGET CODE GENERATION

Event-Based Architecture Definition Language

An explicit state model checker

Objectives Identify solutions of linear equations in two variables.

Predicate Abstraction

Presentation transcript:

Enforcing Concurrent Temporal Behaviors Doron Peled, Dept. of CS University of Warwick

Verification of systems Modeling (translating) Verifying Checking against original code Code, Design Some representation Counterexample Failed. Some feedback information Passed, inform developers!!

Problems: Given as a sequence of states/events: zConcurrent information is lost. zLong and complicated. So where is the error among 2,375 states in the sequence? zIf concurrent/nondeterministic, may not actually happen when running the code under same initial state+input.

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes Initially: turn=1

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes Initially: turn=1 (same)

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

0:START P1 11:c1:=1 12:true 13:end 2:c1:=0 8:c2=0? 7:turn=2? 6:c1:=0 3:c1:=1 11:turn:=2 10:c1:=1 9:critical-1 4:no-op 5:turn=2? no no no noyes yes yes yes 0:START P2 11:c2:=1 12:true 13:end 2:c2:=0 8:c1=0? 7:turn=1? 6:c2:=0 3:c2:=1 11:turn:=1 10:c2:=1 9:critical-2 4:no-op 5:turn=1? no no no noyes yes yes yes

Goals zGuaranteeing the same execution. zMinimal changes to the software. zPreserving concurrency independence. zPreserve the checked property. zApplying the transformation to finite sequences as well as ultimately periodic ones.

First execution again: (p1(0):start) (P2(0):start) [P1(1):c1:=1] [P2(1):c2:=1] yes [p2(2):c2:=0] no

How to obtain the order? zDefine dependency D  (A  A) relation: ya and b are in the same process, or ya and b use or define (update) same variable. zMake the following restrictions on occurrences in  : ya k occurs before b l in the sequence , and ya and b are interdependent.

Causal constraints: (p1(0):start) (P2(0):start) [P1(1):c1:=1] [P2(1):c2:=1] yes [p2(2):c2:=0] no Same process P1 (same program counter)

More causal constraints (p1(0):start) (P2(0):start) [P1(1):c1:=1] [P2(1):c2:=1] yes [p2(2):c2:=0] no Same process P2 (same program counter)

Even more constraints: (p1(0):start) (P2(0):start) [P1(1):c1:=1] [P2(1):c2:=1] yes [p2(2):c2:=0] no The mutual use of variable c1 in both processes.

Need to add to the program: zFor each pair of processes p i and p j with some occurrences a k -->b l there is a variable V ij zAfter a k we perform Free ij : V ij := V ij + 1 zBefore b l we perform Wait ij : wait V ij >0 then V ij := V ij - 1 zCount all actions that need to be synchronized. Make syncrhonization on correct count.

In what sense did we preserve the concurrency? zOne way of looking at a concurrent execution is to observe all the linearizations into total orders. zThe given sequence  is a linearization of some partial order execution E. zBut when we transform the program, we add some actions. zInformally: We obtain E’. When removing the additional actions, we obtain E. zWhen removing the additional actions from lin(E’) we obtain lin(E).

Some notation zCl D (  ) The sequences obtained from  after commuting independent actions. zHide B (S) The sequences obtained from the ones in S by omitting the events in B. zExec(P) The executions of program P. zWe add actions A’ such that D’  (A  A)=D. (dependency between old actions unaffected). zIf we transform the program into a program P’, we obtain that Hide A’ \ A (Exec (P’ ))= Cl D (  )

Preserving a temporal property zSuppose we selected a sequence  since it satisfied (or failed) property L (language). zProblem: when both: yCl D (  )  L  yCl D (  )  L zHow to solve this?

A solution zSearch a graph where each node is one of the equivalent executions, with original node . zAn edge exists between a two nodes if one is obtained from the other by one shuffle of actions. zWhenever the shuffle does not preserve property, insert another Wait/Free pair. Rename such pair of events and make them interdependent (so other occurrences are unaffected). zCost: expensive (can be exponential in number of processes). zNP-complete: May guess the interleaving of the path and the place of bad commutation, then check it. Hardness from Hamiltonian Path.

Simpler approximation zAssume property closed under stuttering. zCheck which actions can affect the propositions that appear in the property. zMake these actions interdependent. zComplexity: Low. Quadratic in number of transitions.

Ultimately periodic sequences. zTest sequences for unbounded length of time.  Finite prefix v, finite recurring sequence w.  Can take care of both parts v, w separately.  One possibility: Make an artificial syncrhonization between the end of v and the beginning of w. zAnother possibility: create a graph, where P are processes, and p i -->p j  E if there are some events a k -->b l belonging to p i, p j, respectively. v w

There are three cases: 1 There is a single strongly connected component. In this case, in some linearizations, the i+1st iteration may start in some processes while the i th iteration still executes in others. 2 The graph includes all the processes in different components. Then there can be arbitrary overtaking between the iterations. 3 The graph does not include all the processes. In this case, it might be that the sequence  was “unfair”, and some additional actions and interactions occurs. Then synchronization is advised.

Conculusions zGiven a counterexample, we may need to execute it on the checked code. zNeed to transform code to enforce execution when nondeterminism present. zMore synchronization for preserving temporal properties. zSeveral cases for preserving ultimately periodic executions.