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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend