types of formal specifications for assertions concurrent
play

Types of Formal Specifications for Assertions Concurrent and - PowerPoint PPT Presentation

Outline Formal specifications CISC422/853: Formal Methods Types of formal specifications: in Software Engineering: assertions invariants Computer-Aided Verification safety and liveness properties How to express safety


  1. Outline � Formal specifications CISC422/853: Formal Methods � Types of formal specifications: in Software Engineering: • assertions • invariants Computer-Aided Verification • safety and liveness properties � How to express safety properties: Topic 7: Specifying, or How to Describe How the System Should (or Should • FSAs, regular expressions, Never Claims Not) Behave � How to express liveness properties: • progress labels, Buechi Automata, Never Claims, Linear Juergen Dingel Temporal Logic, Computation Tree Logic Feb, 2009 � How to manage the complexity of specifications: Readings: • specification patterns • Spin book: Chapter 4 (Defining Correctness Claims), Chapter 6 (Automata and Logic) CISC422/853, Winter 2009 Specifying • Course notes on CTL 2 (Formal) Specifications Observables � What is a specification? � “Atomic propositions” used in a specification � What is a formal specification? � In BIR • global and local variables (in their scope) � Properties of good formal specifications? • existential (anonymous) thread program counter • As precise and detailed as necessary, and as abstract (i.e., unconstraining) as possible Property.existsThread(t, loc5) � In PROMELA • Consistent • Correct (internally, externally) • global and local variables � Why use formal specifications? • end-states, progress states, and accept states ° needed for expression of liveness (progress) properties • Unambiguous ° E.g., non-progress through reserved boolean variable np_ • Sometimes more succinct (false in s iff at least one process is at a control flow state marked • Amenable to automatic analysis with a progress label) ° more on these later • process ids through reserved variable _pid CISC422/853, Winter 2009 Specifying CISC422/853, Winter 2009 Specifying 3 4

  2. Types of Formal Specifications for Assertions Concurrent and Reactive Systems � Assertions � Express a property of observables at particular Example: location � Invariants thread T() { thread T() { � Most basic formal specification; already used by � Safety properties ... ... John von Neumann in 1947 loc loc7: � Liveness properties loc loc7: � In BIR and Promela: assert(b); when b do { when b do { � What kind of correctness claim does an assertion ... make, that is, what does it mean if there is ... assert(x> y); • no assertion violation?: assert(x> y); ... “No matter along which path control has reached the ... location of the assertion, the boolean expression in } } the assertion evaluates to true at that location” ... • an assertion violation?: ... } “There is at least one execution such that the boolean } expression in the assertion does not evaluate to true at that location” CISC422/853, Winter 2009 Specifying CISC422/853, Winter 2009 Specifying 5 6 Example 2: Checking Mutual Exclusion Example 1: Simple Race Condition Using Assertions � Does protocol below ensure mutual exclusion and deadlock freedom? � How can we check this using Bogor or Spin? syst em syst em M M uxTr y uxTr y { syst em syst em M M uxTr y uxTr y { bool ean bool ean f l ag1; l ag1; bool ean f l ag1; bool ean l ag1; bool ean f l ag2; bool ean l ag2; bool ean bool ean f l ag2; l ag2; t hr ead T1 ( ) { t hr ead T1 ( ) { t hr ead T2 ( ) { t hr ead T2 ( ) { t hr ead T1 ( ) { t hr ead T1 ( ) { t hr ead T2 ( ) { t hr ead T2 ( ) { l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: do { f l ag1 : = t r ue; } got o do { f l ag1 : = t r ue; } got o l oc2; l oc2; do { f l ag2 : = t r ue; } got o do { f l ag2 : = t r ue; } got o l oc2; l oc2; do { f l ag1 : = t r ue; } got o l oc2; do { f l ag1 : = t r ue; } got o l oc2; do { f l ag2 : = t r ue; } got o l oc2; do { f l ag2 : = t r ue; } got o l oc2; l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: when ( ! f l ag2) do { } got o when ( ! f l ag2) do { } got o l oc3; l oc3; when ( ! f l ag1) do { } got o when ( ! f l ag1) do { } got o l oc3; l oc3; when ( ! f l ag2) do { } got o when ( ! f l ag2) do { } got o l oc3; l oc3; when ( ! f l ag1) do { } got o when ( ! f l ag1) do { } got o l oc3; l oc3; l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: do { } got o l oc4; do { } got o l oc4; do { } got o l oc4; do { } got o l oc4; do { } got o do { } got o l oc4; l oc4; do { } got o do { } got o l oc4; l oc4; critical regions critical regions l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: do { f l ag1 : = f al se; } got o do { f l ag1 : = f a l se; } got o l oc0; l oc0; do { f l ag2 : = f al se; } got o do { f l ag2 : = f a l se; } got o l oc0; l oc0; do { f l ag1 : = f al se; } got o do { f l ag1 : = f a l se; } got o l oc0; l oc0; do { f l ag2 : = f al se; } got o do { f l ag2 : = f a l se; } got o l oc0; l oc0; } } } } [Source: spinroot.com] CISC422/853, Winter 2009 Specifying CISC422/853, Winter 2009 Specifying 7 8

  3. Example 2: Checking Mutual Exclusion Assertions in Java Using Assertions (Cont’d) To check mutual exclusion, instrument protocol as follows: � Java 1.4 also supports assertions syst em syst em M M uxTr y uxTr y { � What does it mean if a Java assertion is syst em syst em M M uxTr y uxTr y { bool ean bool ean f l ag1; f l ag1; bool ean f l ag1; bool ean f l ag1; bool ean f l ag2; bool ean f l ag2; bool ean f l ag2; bool ean f l ag2; • violated? i nt i nt c; i nt i nt c; • not violated? t hr ead T2 ( ) { t hr ead T2 ( ) { t hr ead T1 ( ) { t hr ead T1 ( ) { t hr ead T2 ( ) { t hr ead T2 ( ) { t hr ead T1 ( ) { t hr ead T1 ( ) { l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: � What’s the difference between assertions in l oc l oc0: l oc l oc0: l oc l oc0: l oc l oc0: do { f l ag1 : = t r ue; } got o l oc2; do { f l ag1 : = t r ue; } got o l oc2; do { f l ag2 : = t r ue; } got o do { f l ag2 : = t r ue; } got o l oc2; l oc2; do { f l ag1 : = t r ue; } got o l oc2; do { f l ag1 : = t r ue; } got o l oc2; do { f l ag2 : = t r ue; } got o l oc2; do { f l ag2 : = t r ue; } got o l oc2; Bogor/Spin and Java? l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: l oc l oc2: when ( ! f l ag1) do { } got o l oc3; when ( ! f l ag1) do { } got o l oc3; when ( ! f l ag2) do { } got o when ( ! f l ag2) do { } got o l oc3; l oc3; when ( ! f l ag1) do { } got o l oc3; when ( ! f l ag1) do { } got o l oc3; when ( ! f l ag2) do { } got o when ( ! f l ag2) do { } got o l oc3; l oc3; l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: l oc l oc3: do { do { c : = c+1; asser t ( c==1) ; c : = c+1; asser t ( c==1) ; } } do { do { c : = c+1; asser t ( c==1) ; c : = c+1; asser t ( c==1) ; } } do { c : = c+1; asser t ( c==1) ; } do { c : = c+1; asser t ( c==1) ; } do { c : = c+1; asser t ( c==1) ; } do { c : = c+1; asser t ( c==1) ; } got o got o l oc4; l oc4; got o l oc4; got o l oc4; got o got o l oc4; l oc4; got o l oc4; got o l oc4; critical regions critical regions l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: l oc l oc4: do { c : = c- 1; do { c : = c- 1; f l ag2 : = f al se; } f l ag2 : = f al se; } do { do { c : = c- 1; c : = c- 1; f l ag1 : = f al se; } f l ag1 : = f al se; } do { c : = c- 1; do { c : = c- 1; f l ag2 : = f al se; } f l ag2 : = f al se; } do { c : = c- 1; do { c : = c- 1; f l ag1 : = f al se; } f l ag1 : = f al se; } got o got o l oc0; l oc0; got o got o l oc0; l oc0; got o l oc0; got o l oc0; got o l oc0; got o l oc0; } } } } What about deadlock freedom? CISC422/853, Winter 2009 Specifying CISC422/853, Winter 2009 Specifying 9 10 Invariants Multiplication Example � Express property of observables that holds at every Consider a simple program with a loop invariant location � What kind of correctness claim does an invariant // assume parameters m and n // assume parameters m and n make, that is, what does it mean if there is count := m; count := m; output := 0; output := 0; • no invariant violation?: “At all locations along all executions of the system, the property // loop invariant: m * n = = output + (count * n) // loop invariant: m * n = = output + (count * n) holds” while (count > 0) do { while (count > 0) do { • an invariant violation?: output := output + n; output := output + n; count := count – 1; “There is at least one location along an execution such that the count := count – 1; } property does not hold at that location” } � How do invariants compare to • assertions? • “loop invariants” in Hoare Logic? [Source: CIS842 @ KSU] CISC422/853, Winter 2009 Specifying CISC422/853, Winter 2009 Specifying 11 12

Recommend


More recommend