Liveness of Communicating Transactions

Similar documents
Communicating Transactions (Extended Abstract)

Bisimulations for Communicating Transactions

A Note on Scope and Infinite Behaviour in CCS-like Calculi p.1/32

Trace semantics: towards a unification of parallel paradigms Stephen Brookes. Department of Computer Science Carnegie Mellon University

The State Explosion Problem

Models of Concurrency

Temporal Logic. Stavros Tripakis University of California, Berkeley. We have designed a system. We want to check that it is correct.

TRINITY COLLEGE DUBLIN. First-Order Reasoning for Higher-Order Concurrency

Failure Diagnosis of Discrete Event Systems With Linear-Time Temporal Logic Specifications

On Compensation Primitives as Adaptable Processes

Introduction to Temporal Logic. The purpose of temporal logics is to specify properties of dynamic systems. These can be either

Communicating Parallel Processes. Stephen Brookes

Trace-based Process Algebras for Real-Time Probabilistic Systems

Structure Preserving Bisimilarity,

Automata-Theoretic Model Checking of Reactive Systems

Lecture 2 Automata Theory

Modal and Temporal Logics

An introduction to process calculi: Calculus of Communicating Systems (CCS)

Safety and Liveness Properties

Verification. Arijit Mondal. Dept. of Computer Science & Engineering Indian Institute of Technology Patna

Timo Latvala. March 7, 2004

A Canonical Contraction for Safe Petri Nets

Lecture 2 Automata Theory

Timed Automata. Semantics, Algorithms and Tools. Zhou Huaiyang

Simply Typed Lambda Calculus

An Introduction to Temporal Logics

Semantics and Verification

Modelling Membranes with Brane Calculi

Chapter 4: Computation tree logic

Introduction to Formal Verification Methods Exercise 4

Coinductive big-step semantics and Hoare logics for nontermination

Topics in Concurrency

Abstractions and Decision Procedures for Effective Software Model Checking

From Liveness to Promptness

Temporal logics and explicit-state model checking. Pierre Wolper Université de Liège

TIMED automata, introduced by Alur and Dill in [3], have

The Underlying Semantics of Transition Systems

Characterizing Fault-Tolerant Systems by Means of Simulation Relations

Guest lecturer: Prof. Mark Reynolds, The University of Western Australia

Conservation of Information

Clojure Concurrency Constructs, Part Two. CSCI 5828: Foundations of Software Engineering Lecture 13 10/07/2014

FAIRNESS FOR INFINITE STATE SYSTEMS

Models for Concurrency

Shared-Variable Concurrency

Introduction to Model Checking. Debdeep Mukhopadhyay IIT Madras

Topics in Concurrency

Revising UNITY Programs: Possibilities and Limitations 1

Benefits of Interval Temporal Logic for Specification of Concurrent Systems

On the coinductive nature of centralizers

Formal Methods for Probabilistic Systems

ESE601: Hybrid Systems. Introduction to verification

Deconstructing CCS and CSP Asynchronous Communication, Fairness, and Full Abstraction

MODEL CHECKING. Arie Gurfinkel

Complexity Issues in Automated Addition of Time-Bounded Liveness Properties 1

Interpreting the Full λ-calculus in the π-calculus

Communication and Concurrency: CCS

Automatic Synthesis of Distributed Protocols

CS 6112 (Fall 2011) Foundations of Concurrency

Reasoning About Imperative Programs. COS 441 Slides 10b

Communicating Multi-Stack Visibly Pushdown Processes

Computation Tree Logic (CTL) & Basic Model Checking Algorithms

Chapter 5: Linear Temporal Logic

What is Temporal Logic? The Basic Paradigm. The Idea of Temporal Logic. Formulas

From EBNF to PEG. Roman R. Redziejowski. Concurrency, Specification and Programming Berlin 2012

CS477 Formal Software Dev Methods

Process Algebras and Concurrent Systems

Finite-State Model Checking

THEORY OF SYSTEMS MODELING AND ANALYSIS. Henny Sipma Stanford University. Master class Washington University at St Louis November 16, 2006

Embedded Systems 2. REVIEW: Actor models. A system is a function that accepts an input signal and yields an output signal.

Communication and Concurrency: CCS. R. Milner, A Calculus of Communicating Systems, 1980

MODEL CHECKING TIMED SAFETY INSTRUMENTED SYSTEMS

Temporal Logic of Actions

Alan Bundy. Automated Reasoning LTL Model Checking

Decentralized Failure Diagnosis of Discrete Event Systems

Bilateral Proofs of Safety and Progress Properties of Concurrent Programs (Working Draft)

Syntax and Semantics of Propositional Linear Temporal Logic

Recursion in Coalgebras

The Polyranking Principle

Revising Distributed UNITY Programs is NP-Complete

Choreographies and Behavioural Contracts on the Way to Dynamic Updates

Timed Automata VINO 2011

Distributed transactions and reversibility

Basics of Linear Temporal Proper2es

Model Checking with CTL. Presented by Jason Simas

Models. Lecture 25: Model Checking. Example. Semantics. Meanings with respect to model and path through future...

Decentralized Control of Discrete Event Systems with Bounded or Unbounded Delay Communication

Concurrent Flexible Reversibility

Overview. overview / 357

CASPA - A Tool for Symbolic Performance Evaluation and Stochastic Model Checking

On Real-time Monitoring with Imprecise Timestamps

Semantic Equivalences and the. Verification of Infinite-State Systems 1 c 2004 Richard Mayr

Probabilistic Model Checking Michaelmas Term Dr. Dave Parker. Department of Computer Science University of Oxford

Introduction to process algebra

Computer-Aided Program Design

Temporal Logic. M φ. Outline. Why not standard logic? What is temporal logic? LTL CTL* CTL Fairness. Ralf Huuck. Kripke Structure

Contextual equivalence

The Join calculus A calculus of mobile agents

Model checking, verification of CTL. One must verify or expel... doubts, and convert them into the certainty of YES [Thomas Carlyle]

A Simplified Approach for Testing Real-Time Systems Based on Action Refinement

Embedded systems specification and design

Transcription:

(joint work with Vasileios Koutavas and Matthew Hennessy) TRINITY COLLEGE DUBLIN COLÁISTE NA TRÍONÓIDE, BAILE ÁTHA CLIATH Dublin Concurrency Workshop 2011

Traditional Transactions Transactions provide an abstraction for error recovery in a concurrent setting.

Traditional Transactions Transactions provide an abstraction for error recovery in a concurrent setting. The transactional system guarantees: Atomicity: Each transaction will either run in its entirety or not at all Consistency: Faults caused by a transaction are automatically detected and rolled-back Isolation: The effects of a transaction are concealed from the rest of the system until the transaction commits Durability: After a transaction commits, its effects are permanent.

Traditional Transactions Transactions provide an abstraction for error recovery in a concurrent setting. The transactional system guarantees: Atomicity: Each transaction will either run in its entirety or not at all Consistency: Faults caused by a transaction are automatically detected and rolled-back Isolation: The effects of a transaction are concealed from the rest of the system until the transaction commits Durability: After a transaction commits, its effects are permanent. However, isolation limits concurrency The semantics of traditional transactions is sequential schedules Traditional transactions do not offer an abstraction for recovery from distributed errors (e.g. deadlocks)

Communicating Transactions We drop isolation to increase concurrency There is no limit on the communication between a transaction and its environment The transactional system guarantees: Atomicity: Each transaction will either run in its entirety or not at all Consistency: Faults caused by a transaction are automatically detected and rolled-back, together with all effects of the transaction to its environment Durability: After all transactions that have interacted commit, their effects are permanent (coordinated checkpointing) We are interested in safety and especially liveness properties First theory of liveness in the presence of transactions We have studied the transactional properties of communicating transactions in [CONCUR 2010]

Safety Safety: Nothing bad will happen [Lamport 77] A safety property can be formulated as a safety test T ; which signals on channel ; when it detects the bad behaviour P passes the safety test T ; when P T ; cannot output on ; This is the negation of passing a may test [DeNicola-Hennessy 84]

Liveness Liveness: Something good will eventually happen [Lamport 77] A liveness property can be formulated as a liveness test T ω which detects and reports good behaviour on ω. P passes the liveness test T ω when all future states of P T ω can output on ω This is a should test [Binksma-Rensink-Vogler 95, Rensink-Vogler 07] It excludes pathological traces We will later see why must testing [DeNicola-Hennessy 84] is not appropriate for transactions

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) co k commit

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) co k commit

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) Default co k commit

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) Alternative co k commit

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) Name co k commit

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) co k commit Main reductions: R-Comm a i = b j a i.p i b j.q j P i Q j i I j J R-Co P co k k Q P R-Emb k / R P k Q R P R k Q R R-Ab P k Q Q

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) co k commit Main reductions: R-Comm a i = b j a i.p i b j.q j P i Q j i I j J R-Co P co k k Q P R-Emb k / R P k Q R P R k Q R R-Ab P k Q Q

TransCCS [CONCUR 2010] Syntax: P, Q ::= µ i.p i guarded choice P Q parallel νa.p hiding µx.p recursion P k Q transaction (k bound in P) co k commit Main reductions: R-Comm a i = b j a i.p i b j.q j P i Q j i I j J R-Co P co k k Q P R-Emb k / R P k Q R P R k Q R R-Ab P k Q Q

Simple Example a.c.ω + e.; a.c.co k + e k r

Simple Example a.c.ω + e.; a.c.co k + e k r

Simple Example a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r r

Simple Example a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm c.ω c.co k k a.c.ω + e.; r r

Simple Example a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm c.ω c.co k k a.c.ω + e.; r R-Comm ω co k k a.c.ω + e.; r r

Simple Example a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm c.ω c.co k k a.c.ω + e.; r R-Comm ω co k k a.c.ω + e.; r R-Co ω r

Simple Example a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm c.ω c.co k k a.c.ω + e.; r R-Comm ω co k k a.c.ω + e.; r R-Co ω r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm ; k a.c.ω + e.; r r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm ; k a.c.ω + e.; r r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm ; k a.c.ω + e.; r R-Ab a.c.ω + e.; r r

Simple Example (a second trace) a.c.ω + e.; a.c.co k + e k R-Emb a.c.ω + e.; a.c.co k + e k a.c.ω + e.; r R-Comm ; k a.c.ω + e.; r R-Ab a.c.ω + e.; r r (The environment is restored)

Simple Example (all traces) R-Ab a.c.ω + e.; a.c.co k + e k r a.c.ω + e.; r R-Emb R-Ab R-Comm P 1 R-Comm P 2 P 2 R-Comm P 3 R-Co ω

Restarting transactions a.c.ω + e.; µx. a.c.co k + e k X

Restarting transactions a.c.ω + e.; µx. a.c.co k + e k X R-Emb R-Ab R-Comm P 1 R-Comm P 2 P 2 R-Comm P 3 R-Co ω

Restarting transactions a.c.ω + e.; µx. a.c.co k + e k X R-Emb R-Ab R-Comm P 1 R-Comm P 2 P 2 R-Comm P 3 R-Co ω Infinitely aborting loop

Compositional Semantics The embedding rule is simple but entangles the processes We need to reason about the behaviour of P Q in terms of P and Q We introduce a compositional Labelled Transition System that uses secondary transactions: P k Q

Compositional Semantics The embedding rule is simple but entangles the processes We need to reason about the behaviour of P Q in terms of P and Q We introduce a compositional Labelled Transition System that uses secondary transactions: P k Q a.c.ω + e.; a.c.co k + e k r emb k a.c.ω + e.; k a.c.ω + e.; k(a) c.ω k a.c.ω + e.; k(c) ω k a.c.ω + e.; co k ω emb k a.c.co k + e k r k(a) c.co k k r k(c) co k k r co k 0

Compositional Semantics The embedding rule is simple but entangles the processes We need to reason about the behaviour of P Q in terms of P and Q We introduce a compositional Labelled Transition System that uses secondary transactions: P k Q a.c.ω + e.; a.c.co k + e k r emb k a.c.ω + e.; k a.c.ω + e.; k(e) c.ω k a.c.ω + e.; ab k a.c.ω + e.; emb k a.c.co k + e k r k(e) k r ab k r

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces L( a.c.co k + e k r ) = {ɛ, a c, r}

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces L( a.c.co k + e k r ) = {ɛ, a c, r} (Non-prefix-closed set)

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces L( a.c.co k + e k r ) = {ɛ, a c, r} (Non-prefix-closed set) L(µX. a.c.co k + e k X ) = {ɛ, a c}

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces L( a.c.co k + e k r ) = {ɛ, a c, r} (Non-prefix-closed set) L(µX. a.c.co k + e k X ) = {ɛ, a c} (Atomicity: all-or-nothing)

Compositional Semantics (2) The behaviour of processes in TransCCS can be understood by CCS-like Clean traces derived by the LTS that: consider only traces where all actions are eventually committed ignore transactional annotations on the traces L( a.c.co k + e k r ) = {ɛ, a c, r} (Non-prefix-closed set) L(µX. a.c.co k + e k X ) = {ɛ, a c} (Atomicity: all-or-nothing) enable compositional reasoning: L(P Q) = L(P) zip L(Q) L(P) L(Q) implies L(P R) L(Q R)

Safety Definition (Basic Observable) P a iff there exists P such that P P a Basic observable actions are permanent

Safety Definition (Basic Observable) P a iff there exists P such that P P a Basic observable actions are permanent Definition (P passes safety test T ; ) P cannot T ; when P T ; ;

Safety Definition (Basic Observable) P a iff there exists P such that P P a Basic observable actions are permanent Definition (P passes safety test T ; ) P cannot T ; when P T ; ; Definition (Safety preservation) S safe I when T ;. S cannot T ; implies I cannot T ;

Safety Definition (Basic Observable) P a iff there exists P such that P P a Basic observable actions are permanent Definition (P passes safety test T ; ) P cannot T ; when P T ; ; Definition (Safety preservation) S safe I when T ;. S cannot T ; implies I cannot T ; Theorem (Characterization of safety preservation) S safe I iff L(S) L(I )

Liveness Definition (P Passes liveness Test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω

Liveness Definition (P Passes liveness Test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω a.c.ω + e.; µx. a.c.co k + e k X R-Emb R-Ab P 1 R-Comm R-Comm P 2 P 2 R-Comm P 3 R-Co ω

Liveness Definition (P Passes liveness Test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω a.c.ω + e.; µx. a.c.co k + e k X R-Emb R-Ab P 1 R-Comm R-Comm P 2 P 2 must testing would consider the infinite loop R-Comm P 3 R-Co ω

Liveness Definition (P passes liveness test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω Definition (Tree Failures [Rensink-Vogler 07]) (t, Ref ) is a tree failure of P when P. P t = CL P and L(P ) Ref = F(P) = {(t, Ref ) tree failure of P} Ref t

Liveness Definition (P passes liveness test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω Definition (Tree Failures [Rensink-Vogler 07]) (t, Ref ) is a tree failure of P when P. P t = CL P and L(P ) Ref = F(P) = {(t, Ref ) tree failure of P} Ref t Ref is generally non-prefix-closed

Liveness Definition (P passes liveness test T ω [Rensink-Vogler 07]) P shd T ω when R. P T ω R implies R ω Definition (Tree Failures [Rensink-Vogler 07]) (t, Ref ) is a tree failure of P when P. P t = CL P and L(P ) Ref = F(P) = {(t, Ref ) tree failure of P} Ref t Ref is generally non-prefix-closed Theorem (Characterization of liveness preservation) S live I iff F(S) F(I )

Simple Examples Let S ab = µx. a.b.co k k X L(S ab ) = {ɛ, ab} F(S ab ) = {(ɛ, S\ab), (ab, S) S A }

Simple Examples Let S ab = µx. a.b.co k k X L(S ab ) = {ɛ, ab} F(S ab ) = {(ɛ, S\ab), (ab, S) S A } S ab safe I 1 = a.b.co k k 0 L(I 1 ) = {ɛ, ab} S ab live I 1 F(I 1 ) = {(ɛ, S), (ab, S) S A }

Simple Examples Let S ab = µx. a.b.co k k X L(S ab ) = {ɛ, ab} F(S ab ) = {(ɛ, S\ab), (ab, S) S A } S ab safe I 1 = a.b.co k k 0 L(I 1 ) = {ɛ, ab} S ab live I 1 F(I 1 ) = {(ɛ, S), (ab, S) S A } S ab safe I 2 = µx. a.b.co k + e k X L(I 2 ) = L(S ab ) S ab live I 2 F(I 2 ) = F(S ab )

Comparison with CCS (1) Safety in TransCCS is characterized by non-prefix-closed sets of traces Safety in CCS is characterized by prefix-closed sets of traces

Comparison with CCS (1) Safety in TransCCS is characterized by non-prefix-closed sets of traces Safety in CCS is characterized by prefix-closed sets of traces TransCCS safety tests have the same distinguishing power as CCS safety tests If in CCS P safe Q then also in TransCCS P safe Q

Comparison with CCS (1) Safety in TransCCS is characterized by non-prefix-closed sets of traces Safety in CCS is characterized by prefix-closed sets of traces TransCCS safety tests have the same distinguishing power as CCS safety tests If in CCS P safe Q then also in TransCCS P safe Q No way to encode non-prefix-closed traces in CCS; thus no fully-abstract translation from TransCCS to CCS

Comparison with CCS (2) Liveness in TransCCS is characterized by tree failures Liveness in CCS is characterized by a more complex model [Rensink-Vogler 07]

Comparison with CCS (2) Liveness in TransCCS is characterized by tree failures Liveness in CCS is characterized by a more complex model [Rensink-Vogler 07] TransCCS liveness tests have more distinguishing power than CCS liveness tests In CCS a.(b.c + b.d) live a.b.c + a.b.d In TransCCS a.(b.c + b.d) live a.b.c + a.b.d (a, {bd}) F(a.(b.c + b.d)) (a, {bd}) F(a.b.c + a.b.d) TransCCS distinguishing liveness test in the paper

Comparison with CCS (2) Liveness in TransCCS is characterized by tree failures Liveness in CCS is characterized by a more complex model [Rensink-Vogler 07] TransCCS liveness tests have more distinguishing power than CCS liveness tests In CCS a.(b.c + b.d) live a.b.c + a.b.d In TransCCS a.(b.c + b.d) live a.b.c + a.b.d (a, {bd}) F(a.(b.c + b.d)) (a, {bd}) F(a.b.c + a.b.d) TransCCS distinguishing liveness test in the paper Thus no sound translation from TransCCS to CCS that is the identity on CCS terms

Also in [APLAS 2010] Canonical class of tests for liveness and safety See how restarting transactions add fault tolerance to CCS (Ex. 6) A sound, but incomplete bisimulation proof method, using the clean LTS transitions Many examples

Conclusions Communicating transactions: Traditional transactions without the isolation requirement No limit on communication or concurrency Simple safety and liveness theory First theory of liveness in the presence of transactions Future directions: Reference implementation/evaluation of the construct in a programming language. Advertisement Joint Trinity/Microsoft Research PhD on extending Haskell with communicating transactions. We need a good student :)

ACD Properties A commit step makes the effects of the transaction permanent (Durability ) a.b.ω + e.; µx. a.b.co k + e k X R-Emb P1 R-Comm P2 R-Comm P2 R-Comm P3 R-Co ω R-Ab An abort step: restarts the transaction rolls-back embedded processes to their state before embedding (Consistency ) does not roll-back actions that happened before embedding does not affect non-embedded processes The semantics of transactions transactions are non-prefix-closed traces (Atomicity ).