2015 Concurrency: logical properties 1 ©Magee/Kramer 2 nd Edition Chapter 14 Logical Properties Satisfied? Not satisfied?

Slides:



Advertisements
Similar presentations
Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
Advertisements

1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Part 3: Safety and liveness
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
CS6133 Software Specification and Verification
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
UPPAAL Introduction Chien-Liang Chen.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
Concurrency: monitors & condition synchronization1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8b Monitors.
Concurrency: safety & liveness properties1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 14 Safety and.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
Temporal Specification Chris Patel Vinay Viswanathan.
Chapter 6 - Repetition. Introduction u Many applications require certain operations to be carried out more than once. Such situations require repetition.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Review of the automata-theoretic approach to model-checking.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
© 2004 Pearson Addison-Wesley. All rights reserved5-1 Iterations/ Loops The while Statement Other Repetition Statements.
Describing Syntax and Semantics
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
System Design Research Laboratory Specification-based Testing with Linear Temporal Logic Li Tan Oleg Sokolsky Insup Lee University of Pennsylvania.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CHAPTER 10 Recursion. 2 Recursive Thinking Recursion is a programming technique in which a method can call itself to solve a problem A recursive definition.
Concurrency: shared objects & mutual exclusion1 ©Magee/Kramer 2 nd Edition Chapter 4 Shared Objects & Mutual Exclusion.
CC0002NI – Computer Programming Computer Programming Er. Saroj Sharan Regmi Week 7.
Concurrency: introduction1 ©Magee/Kramer Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
The Critical Section Problem
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 5 Introduction to Concurrency:
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
CS6133 Software Specification and Verification
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 15 More Advanced Program Properties: Temporal logic and jSpin John Gurd,
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Safety & Liveness Properties
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Controlling Execution Programming Right from the Start with Visual Basic.NET 1/e 8.
Saeed Ghanbartehrani Summer 2015 Lecture Notes #5: Programming Structures IE 212: Computational Methods for Industrial Engineering.
1 Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Java Programming: From Problem Analysis to Program Design, 4e Chapter 5 Control Structures II: Repetition.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Section 1.4. Propositional Functions Propositional functions become propositions (and have truth values) when their variables are each replaced by a value.
Agenda  Quick Review  Finish Introduction  Java Threads.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
Introduction to Programming G50PRO University of Nottingham Unit 6 : Control Flow Statements 2 Paul Tennent
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
1 Sections 7.2 – 7.7 Nested Control Statements Fundamentals of Java: AP Computer Science Essentials, 4th Edition Lambert / Osborne.
Chapter 4 Repetition Statements (loops)
CIS 842: Specification and Verification of Reactive Systems
Program Synthesis is a Game
Formal Methods for Software Engineering
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
LOOPS The loop is the control structure we use to specify that a statement or group of statements is to be repeatedly executed. Java provides three kinds.
COMP60621 Designing for Parallelism
Presentation transcript:

2015 Concurrency: logical properties 1 ©Magee/Kramer 2 nd Edition Chapter 14 Logical Properties Satisfied? Not satisfied?

2015 Concurrency: logical properties 2 ©Magee/Kramer 2 nd Edition Logical Properties Concepts : modeling properties that refer to states Models : fluent – characterization of abstract state based on action sets fluent linear temporal logic FLTL Practice : assert – Java proposition on the state of variables

2015 Concurrency: logical properties 3 ©Magee/Kramer 2 nd Edition Background  Temporal Logic due to Pneuli (1977) is a popular means to describe process properties in logic.  Use propositions on selected variable states at particular points in program executions.  Realized as the assert construct in Java. States in an LTS model based on actions or events? HOW?  Introduce fluents to describe abstract “states”.  Express both safety and liveness properties as fluent propositions. Pnueli, A. (1977). The Temporal Logic of Programs. Proc. of the 18 th IEEE Symposium on the Foundations of Computer Science, Oct/Nov 1977, pp Robert A. Kowalski, Marek J. Sergot (1986). A Logic-based Calculus of Events. New Generation Comput. 4(1): 67-95

2015 Concurrency: logical properties 4 ©Magee/Kramer 2 nd Edition Fluents const False = 0 const True = 1 SWITCH = (on->{off, power_cut}->SWITCH). fluent LIGHT = initially False fluent DARK = initially True LIGHT DARK Time on off TRUE FALSE LIGHT

2015 Concurrency: logical properties 5 ©Magee/Kramer 2 nd Edition Fluents fluent FL = initially B defines a fluent FL that is initially true if the expression B is true and initially false if the expression B is false. FL becomes true when any of the initiating (or starting) actions {s 1,…,s n } occur and false when any of the terminating (or ending) actions {e 1,…,e n } occur. If the term initially B is omitted then FL is initially false. The same action may not be used as both an initiating and terminating action. A fluent thus describes an abstract state that is entered by executing any of the actions in {s 1,…,s n }, and exited by executing any of the actions in {e 1,…,e n }. abstract state sisi eiei

2015 Concurrency: logical properties 6 ©Magee/Kramer 2 nd Edition Fluent Linear Temporal Logic (FLTL) Expressions  FLTL expression can be constructed using Boolean operators and quantifiers: &&, ||, !, ->,, forall, exists  E.g., If the light is on, power is also on:  All lights are on: fluent LIGHT[i:1..2] =  At least one light is on: fluent LIGHT[i:1..2] = fluent LIGHT = fluent POWER = LIGHT -> POWER forall[i:1..2] LIGHT[i] exists[i:1..2] LIGHT[i]

2015 Concurrency: logical properties 7 ©Magee/Kramer 2 nd Edition Fluent Linear Temporal Logic (FLTL) Expressions  There are five temporal operators in FLTL Always [] Eventually <> Until U Weak until W Next time X  Amongst the five operators, always [] and eventually <> are the two most commonly used ones.  Until, Weak until and Next time allows complex relation between abstract states.

2015 Concurrency: logical properties 8 ©Magee/Kramer 2 nd Edition Temporal propositions const False = 0 const True = 1 SWITCH = (power_on -> OFF), OFF = (on -> ON | power_off -> SWITCH), ON = (off-> OFF | power_off -> SWITCH). fluent LIGHT = fluent POWER = assert OK = [](LIGHT -> POWER) always implies

2015 Concurrency: logical properties 9 ©Magee/Kramer 2 nd Edition Safety Properties: Mutual Exclusion const N = 2 range Int = 0..N SEMAPHORE(I=0) = SEMA[I], SEMA[v:Int] = (up->SEMA[v+1] |when(v>0) down->SEMA[v-1] ). LOOP = (mutex.down->enter->exit->mutex.up->LOOP). ||SEMADEMO = (p[1..N]:LOOP || {p[1..N]}::mutex:SEMAPHORE(2)). fluent CRITICAL[i:1..N] =  Two processes are not in their critical sections simultaneously?

2015 Concurrency: logical properties 10 ©Magee/Kramer 2 nd Edition Safety Properties: Mutual Exclusion  No two processes can be at critical sections simultaneously: assert MUTEX = []!(CRITICAL[1] && CRITICAL[2])  LTSA compiles the assert statement into a safety property process with an ERROR state.  The linear temporal logic formula []F – always F – is true if and only if the formula F is true at the current instant and at all future instants.

2015 Concurrency: logical properties 11 ©Magee/Kramer 2 nd Edition Safety Properties: Mutual Exclusion  General expression of the mutual exclusion property for N processes: Trace to property violation in MUTEX: p.1.mutex.down p.1.enterCRITICAL.1 p.2.mutex.downCRITICAL.1 p.2.enterCRITICAL.1 && CRITICAL.2 assert MUTEX_N(N=2) = []!(exists [i:1..N-1] (CRITICAL[i] && CRITICAL[i+1..N] ))

2015 Concurrency: logical properties 12 ©Magee/Kramer 2 nd Edition Safety Properties: Oneway in Single-Lane Bridge  Abbreviating exists[i:R] FL[i] as FL[R] const N = 2 // number of each type of car range ID= 1..N // car identities fluent RED[i:ID] = fluent BLUE[i:ID] = assert ONEWAY = []!(exists[i:ID] RED[i] && exists[j:ID] BLUE[j]) assert ONEWAY = []!(RED[ID] && BLUE[ID])

2015 Concurrency: logical properties 13 ©Magee/Kramer 2 nd Edition Single Lane Bridge - safety property ONEWAY property ONEWAY =(red[ID].enter -> RED[1] |blue.[ID].enter -> BLUE[1] ), RED[i:ID] = (red[ID].enter -> RED[i+1] |when(i==1)red[ID].exit -> ONEWAY |when(i>1) red[ID].exit -> RED[i-1] ), // i is a count of red cars on the bridge BLUE[i:ID]= (blue[ID].enter-> BLUE[i+1] |when(i==1)blue[ID].exit -> ONEWAY |when( i>1)blue[ID].exit -> BLUE[i-1] ). // i is a count of blue cars on the bridge The fluent proposition is more concise as compared with the property process ONEWAY. This is usually the case where a safety property can be expressed as a relationship between abstract states of a system.

2015 Concurrency: logical properties 14 ©Magee/Kramer 2 nd Edition Liveness Properties  First red car must eventually enter the bridge:  To check the liveness property, LTSA transforms the negation of the assert statement in terms of a Büchi automaton.  A Büchi automaton recognizes an infinite trace if that trace passes through an acceptance state infinitely often. The linear temporal logic formula <>F – eventually F – is true if and only if the formula F is true at the current instant or at some future instant. assert FIRSTRED = <>red[1].enter 1 red.1.enter 0 Büchi Automaton

2015 Concurrency: logical properties 15 ©Magee/Kramer 2 nd Edition Liveness Properties: Progress Properties  Compose the Büchi automaton and the original system.  Search for acceptance state in strong connected components.  Failure of the search implies no trace can satisfy the Buchi automaton.  It validates that the assert property holds.  Red and blue cars enter the bridge infinitely often. assert REDCROSS = forall [i:ID] []<>red[i].enter assert BLUECROSS = forall [i:ID] []<>blue[i].enter assert CROSS = (REDCROSS && BLUECROSS)

2015 Concurrency: logical properties 16 ©Magee/Kramer 2 nd Edition Liveness Properties: Response Properties  If a red car enters the bridge, it should eventually exit.  It does not stop in the middle or fall over the side!  Such kind of properties is sometimes termed “response” properties, which follows the form: [](request-> <>reply)  This form of liveness property cannot be specified using the progress properties discussed earlier. assert REDEXIT = forall [i:ID] [](red[i].enter -> <>red[i].exit)

2015 Concurrency: logical properties 17 ©Magee/Kramer 2 nd Edition Fluent Linear Temporal Logic (FLTL)  There are five operators in FLTL Always [] Eventually <> Until U Weak until W Next time X  Amongst the five operators, always [] and eventually <> are the two most commonly used ones.  Until, Weak until and Next time allows complex relation between abstract states.

2015 Concurrency: logical properties 18 ©Magee/Kramer 2 nd Edition Summary  A fluent is defined by a set of initiating actions and a set of terminating actions.  At a particular instant, a fluent is true if and only if it was initially true or an initiating action has previously occurred and, in both cases, no terminating action has yet occurred.  In general, we don’t differentiate safety and liveness properties in fluent linear temporal logic FLTL.  We verify an LTS model against a given set of fluent propositions.  LTSA evaluates the set of fluents that hold each time an action has taken place in the model.

2015 Concurrency: logical properties 19 ©Magee/Kramer 2 nd Edition Course Outline  Processes and Threads  Concurrent Execution  Shared Objects & Interference  Monitors & Condition Synchronization  Deadlock  Safety and Liveness Properties  Model-based Design (Case Study)  Dynamic systems  Passing  Concurrent Software Architectures Concepts Models Practice  Timed Systems  Program Verification  Logical Properties The main basic Advanced topics …