Concurrency: safety & liveness properties1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 14 Safety and.

Slides:



Advertisements
Similar presentations
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Advertisements

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Partial Order Reduction: Main Idea
Models of Concurrency Manna, Pnueli.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
5. Liveness and Guarded Methods Prof. O. Nierstrasz Selected material © Magee and Kramer.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
CSC321 §6 Modelling Processes using FSP 1 Section 6 Modelling Processes using FSP.
Concurrency: monitors & condition synchronization1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8b Monitors.
1 CSC321 §2 Concurrent Programming Abstraction & Java Threads Section 2 Concurrent Programming Abstraction & Java Threads.
Outline. Theorem For the two processor network, Bit C(Leader) = Bit C(MaxF) = 2[log 2 ((M + 2)/3.5)] and Bit C t (Leader) = Bit C t (MaxF) = 2[log 2 ((M.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 12 The Critical Section problem John Gurd, Graham Riley Centre for Novel.
Formal Methods for Software Engineering Lecture, Part II: Liveness.
CP — Concurrent Programming 5. Safety and Liveness Properties Prof. O. Nierstrasz Wintersemester 2005 / 2006.
1 Concurrency Specification. 2 Outline 4 Issues in concurrent systems 4 Programming language support for concurrency 4 Concurrency analysis - A specification.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
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.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti Part 4: Specifications.
ACS-4902 R. McFadyen 1 Database Concurrency Control Deadlock Deadlock occurs when each transaction in a set is waiting for another transaction in the set.
Basic Business Statistics, 10e © 2006 Prentice-Hall, Inc. Chap 9-1 Chapter 9 Fundamentals of Hypothesis Testing: One-Sample Tests Basic Business Statistics.
Concurrency: model-based design ©Magee/Kramer Claus Brabrand University of Aarhus Model-Based Design Concurrency.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
Concurrency: Deadlock1 ©Magee/Kramer 2 nd Edition Chapter 6 Deadlock.
CSC321 §9 Deadlock 1 Section 9 Deadlock. CSC321 §9 Deadlock 2 Deadlock: four necessary and sufficient conditions  Serially reusable resources: the processes.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
Business Statistics, A First Course (4e) © 2006 Prentice-Hall, Inc. Chap 9-1 Chapter 9 Fundamentals of Hypothesis Testing: One-Sample Tests Business Statistics,
Concurrency: introduction1 ©Magee/Kramer Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 5 Introduction to Concurrency:
Guide to State Transition Diagram. 2 Contents  What is state transition diagram?  When is state transition diagram used?  What are state transition.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
Specifying and Verifying Event-based Fairness Enhanced Systems 1 ICFEM 2008 Specifying and Verifying Event-based Fairness Enhanced Systems Jun SUN, Yang.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 15 More Advanced Program Properties: Temporal logic and jSpin John Gurd,
2015 Concurrency: processes & threads 1 ©Magee/Kramer 2 nd Edition Chapter 2 Processes & Threads.
CSC321 §6 Modelling Processes using FSP 1 Chapter 6 Modelling Processes using FSP.
Safety & Liveness Properties
Lecture 6-1 Computer Science 425 Distributed Systems CS 425 / ECE 428 Fall 2013 Indranil Gupta (Indy) September 12, 2013 Lecture 6 Global Snapshots Reading:
CSC321 §10 Safety & Liveness Properties 1 Section 10 Safety & Liveness Properties.
1 Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
2015 Concurrency: logical properties 1 ©Magee/Kramer 2 nd Edition Chapter 14 Logical Properties Satisfied? Not satisfied?
Conditional Probability Mass Function. Introduction P[A|B] is the probability of an event A, giving that we know that some other event B has occurred.
1 Nantes, en Bretagne Nantes in Brittany La Cour des Comptes de Bretagne Le Château des ducs de Bretagne are situated in Nantes Spectacle de Royal de Luxe.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Concurrency Control Introduction Lock-Based Protocols
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.
Lecture 04: Theory of Automata:08 Transition Graphs.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Concurrency: processes & threads1 ©Magee/Kramer 2 nd Edition Chapter 2 Processes & Threads.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8 Introduction to Modelling Concurrency John Gurd, Graham Riley Centre for.
Chapter 6 Deadlock.
COMP60611 Fundamentals of Parallel and Distributed Systems
COMP60611 Fundamentals of Parallel and Distributed Systems
COMP60621 Designing for Parallelism
Chapter 3: Selection Structures: Making Decisions
Formal Methods for Software Engineering
Linear Time Properties
CSC312 Automata Theory Transition Graphs Lecture # 9
Chapter 3: Selection Structures: Making Decisions
COMP60621 Designing for Parallelism
COMP60621 Designing for Parallelism
Presentation transcript:

Concurrency: safety & liveness properties1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 14 Safety and liveness properties Len Freeman, Graham Riley Centre for Novel Computing School of Computer Science University of Manchester

Concurrency: safety & liveness properties2 ©Magee/Kramer 2 nd Edition Chapter 7 Safety & Liveness Properties

Concurrency: safety & liveness properties3 ©Magee/Kramer 2 nd Edition safety & liveness properties Concepts : properties: true for every possible execution safety : nothing bad happens liveness : something good eventually happens Models :safety : no reachable ERROR/STOP state progress : an action is eventually executed fair choice and action priority (a subset of liveness properties) Aim : property satisfaction.

Concurrency: safety & liveness properties4 ©Magee/Kramer 2 nd Edition  STOP or deadlocked state (no outgoing transitions)  ERROR process (-1) to detect erroneous behaviour 7.1 Safety ACTUATOR =(command->ACTION), ACTION =(respond->ACTUATOR |command->ERROR). Trace to ERROR: command  analysis using LTSA: (shortest trace) A safety property asserts that nothing bad happens.

Concurrency: safety & liveness properties5 ©Magee/Kramer 2 nd Edition Safety - property specification  ERROR conditions state what is not required (cf. exceptions).  in complex systems, it is usually better to specify safety properties by stating directly what is required. property SAFE_ACTUATOR = (command -> respond -> SAFE_ACTUATOR ).  analysis using LTSA as before.

Concurrency: safety & liveness properties6 ©Magee/Kramer 2 nd Edition Safety properties property POLITE = Property that it is polite to knock before entering a room. Traces: knock  enterenter knock  knock (knock->enter->POLITE). In all states, all the actions in the alphabet of a property are eligible choices. Transitions not allowed by property lead to ERROR

Concurrency: safety & liveness properties7 ©Magee/Kramer 2 nd Edition Safety properties Safety property P defines a deterministic process that asserts that any trace including actions in the alphabet of P, is accepted by P. Thus, if P is composed with S, then traces of shared actions (in the alphabet of S  alphabet of P) must also be valid traces of P, otherwise ERROR is reachable. Transparency of safety properties : Since all actions in the alphabet of a property are eligible choices, composing a property with a set of processes does not affect their correct behavior. However, if a behavior can occur which violates the safety property, then ERROR is reachable. Properties must be deterministic to be transparent.

Concurrency: safety & liveness properties8 ©Magee/Kramer 2 nd Edition Safety properties  How can we specify that some action, disaster, never occurs? property CALM = STOP + {disaster}.

Concurrency: safety & liveness properties9 ©Magee/Kramer 2 nd Edition Safety – Dining philosopher behaviour? (Ch 6) PHIL(I=0) = (when (I%2==0) sitdown->left.get->right.get ->eat->left.put->right.put->arise->PHIL |when (I%2==1) sitdown->right.get->left.get ->eat->left.put->right.put->arise->PHIL ). FORK = (get->put->FORK).

Concurrency: safety & liveness properties10 ©Magee/Kramer 2 nd Edition property OK = (sitdown->arise>OK). ?? property OK1 = (arise>eat->OK1). ?? ||DINERS(N=5)= forall [i:0..N-1] (phil[i]:OK||phil[i]:PHIL(i) ||{phil[i].left,phil[((i-1)+N)%N].right}::FORK). Safety – philosopher behaviour… ||DINERS(N=5)= forall [i:0..N-1] (phil[i]:PHIL(i) ||{phil[i].left,phil[((i-1)+N)%N].right}::FORK). Check safety using LTSA.

Concurrency: safety & liveness properties11 ©Magee/Kramer 2 nd Edition 7.3 Liveness A safety property asserts that nothing bad happens. A liveness property asserts that something good eventually happens. Locks: Does every thread eventually get a lock? ie. make PROGRESS? A progress property (a type of liveness property) that asserts that it is always the case that an action is eventually executed. Progress is the opposite of starvation, the name given to a concurrent programming situation in which an action is never executed. Simple to specify and quite useful.

Concurrency: safety & liveness properties12 ©Magee/Kramer 2 nd Edition Progress properties - fair choice COIN =(toss->heads->COIN |toss->tails->COIN). Fair Choice: If a choice over a set of transitions is executed infinitely often, then every transition in the set will be executed infinitely often. If a coin were tossed an infinite number of times, we would expect that heads would be chosen infinitely often and that tails would be chosen infinitely often. This requires Fair Choice - a scheduling issue…

Concurrency: safety & liveness properties13 ©Magee/Kramer 2 nd Edition Progress properties progress P = {a1,a2..an} defines a progress property P which asserts that in an infinite execution of a target system, at least one of the actions a1,a2..an will be executed infinitely often. COIN system: progress HEADS = {heads} ? progress TAILS = {tails} ? LTSA check progress: No progress violations detected.

Concurrency: safety & liveness properties14 ©Magee/Kramer 2 nd Edition Progress properties Suppose that there were two possible coins that could be picked up: TWOCOIN = (pick->COIN|pick->TRICK), TRICK = (toss->heads->TRICK), COIN = (toss->heads->COIN|toss->tails->COIN). TWOCOIN: progress HEADS = {heads} ? progress TAILS = {tails} ? a trick coin and a regular coin……

Concurrency: safety & liveness properties15 ©Magee/Kramer 2 nd Edition Progress properties progress HEADSorTails = {heads,tails} ? progress HEADS = {heads} progress TAILS = {tails} LTSA check progress Progress violation: TAILS Trace to terminal set of states: pick Cycle in terminal set: toss heads Actions in terminal set: {heads, toss}

Concurrency: safety & liveness properties16 ©Magee/Kramer 2 nd Edition Progress analysis A terminal set of states is one in which every state is reachable from every other state in the set via one or more transitions, and there is no transition from within the set to any state outside the set. Terminal sets for TWOCOIN: {1,2} and {3,4,5} Given fair choice, each terminal set represents an execution in which each action used in a transition in the set is executed infinitely often. Since there is no transition out of a terminal set, any action that is not used in the set cannot occur infinitely often in all executions of the system - and hence represents a potential progress violation!

Concurrency: safety & liveness properties17 ©Magee/Kramer 2 nd Edition Progress analysis A progress property is violated if analysis finds a terminal set of states in which none of the progress set actions appear. progress TAILS = {tails} in {1,2} Default: given fair choice, for every action in the alphabet of the target system, that action will be executed infinitely often. This is equivalent to specifying a separate progress property for every action. Default analysis for TWOCOIN?

Concurrency: safety & liveness properties18 ©Magee/Kramer 2 nd Edition Progress analysis Progress violation for actions: {pick, tails} Trace to terminal set of states: pick Cycle in terminal set: toss heads Actions in terminal set: {heads, toss} Default analysis for TWOCOIN: separate progress property for every action. If the default holds, then every other progress property holds i.e. every action is executed infinitely often and system consists of a single terminal set of states.

Concurrency: safety & liveness properties19 ©Magee/Kramer 2 nd Edition Progress - action priority Action priority expressions describe scheduling properties: ||C = (P||Q)<<{a1,…,an} specifies a composition in which the actions a1,..,an have higher priority than any other action in the alphabet of P||Q including the silent action tau. In any choice in this system which has one or more of the actions a1,..,an labeling a transition, the transitions labeled with lower priority actions are discarded. High Priority (“ << ”) ||C = (P||Q)>>{a1,…,an} specifies a composition in which the actions a1,..,an have lower priority than any other action in the alphabet of P||Q including the silent action tau. In any choice in this system which has one or more transitions not labeled by a1,..,an, the transitions labeled by a1,..,an are discarded. Low Priority (“ >> ”)

Concurrency: safety & liveness properties20 ©Magee/Kramer 2 nd Edition Progress - action priority NORMAL =(work->play->NORMAL |sleep->play->NORMAL). ||HIGH =(NORMAL)<<{work}.||LOW =(NORMAL)>>{work}. Action priority simplifies the resulting LTS by discarding lower priority actions from choices.

Concurrency: safety & liveness properties21 ©Magee/Kramer 2 nd Edition Summary  Concepts properties: true for every possible execution safety:nothing bad happens liveness: something good eventually happens  Models safety:no reachable ERROR/STOP state compose safety properties at appropriate stages progress: an action is eventually executed fair choice, action priority apply progress check on the final target system model Aim : property satisfaction