1 / 33

CSE 555 Protocol Engineering

CSE 555 Protocol Engineering. Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032). Correctness Requirements. Topics (Ch. 6). Correctness criteria Reasoning about behavior

willianm
Download Presentation

CSE 555 Protocol Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 555Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032)

  2. Correctness Requirements

  3. Topics (Ch. 6) • Correctness criteria • Reasoning about behavior • Assertions and system invariants • Deadlocks and bad cycles • Temporal claims 4-1-3

  4. Correctness Criteria • What does it mean for a design to be correct (i.e., to validate a design)? • A design can be proven correct wrt to specific correctness criteria • Logical correctness is concerned primarily with possibilities, not with probabilities • Some fairly general correctness criteria: • Absence of deadlocks • Absence of livelocks • No improper terminations • Problem: high complexity even with finite state models • A design should be provably correct • Proving even simple protocol properties, such as absence of deadlocks, is PSPACE hard 4-1-4

  5. Dealing With Complexity • Validation methods need to solve complexity problems: • Methods should allow correctness analysis of large models • Methods should provide techniques for reducing complexity of models (Ch. 8 and 11) • Ability to express large models despite complexity depends on a careful choice of correctness criteria • PROMELA’s choice of correctness criteria: support several independent levels of complexity • Simple and straight-forward requirements are checked independently of the others • Example: Absence of deadlocks • Slightly more complicated requirements have higher computation cost • Example: Absence of livelocks • More sophisticated requirements are the most expensive to check • Techniques of reducing complexity are applicable here (Ch. 11) 4-1-5

  6. Basic Types of Claims • Two types of correctness requirements: • Safety: set of properties the system may not violate, i.e., bad things that should be avoided (e.g., invalid end states) • Liveness: set of properties the system must satisfy, i.e., good things that capture the required functionality of a system (e.g., non-progress cycles) • Function of a verification system • Need not, and cannot, determine what is good or bad • It can only help the designer to determine what is possible and what is not • For a verifier, there are two types of correctness claims • Claims about reachable and unreachablestates state properties (e.g., system invariant, process assertion) • Claims about feasible and infeasible executions (i.e., sequence of states)  path properties (finite or infinite (e.g., cyclic)) 4-1-6

  7. Reasoning About Behavior • Correctness criteria can be formalized as claims about the behavior of a PROMELA validation model • Two general types of claims about a given behavior: • Inevitable; or • Impossible • Suffice to support only one type of claim • Claim of one type implicitly defines a complementary and equivalent claim of the other type • PROMELA’s expression of correctness criteria: • Define behaviors that are claimed to be impossible 4-1-7

  8. Reasoning About Behavior (Cont’d) • How to state that a given behavior is inevitable: • All deviant behaviors are impossible • How to express an assertion stating that a condition is invariantly true: • Correctness claim: assertion is impossible to be violated 4-1-8

  9. Definition of Terms • A state of a validation model is completely defined by: • Specification of all values for local and global variables • All control flow points of running processes • Contents of all message channels • An execution sequence: • A finite, ordered set of states • The behavior of a validation model: • Defined completely by the set of all possible execution sequences • Model can reach a given state by executing PROMELA statements • Model can be placed in a given state by: • Assignment of the appropriate values to variables, control flow points, and channels 4-1-9

  10. Valid Execution Sequence • Any arbitrary set of states do not necessarily form a valid execution sequence • A finite, ordered set of states is valid for a given PROMELA model M if it satisfies two criteria: • The first state (state 1) of the sequence is the initial system state of M: • All variables initialized to zero • All message channels empty • Only init process active and set in its initial state • If M is placed in state i, there is at least one executable statement that can bring it to the state i+1 4-1-10

  11. Terminating and Cyclic Sequences • Terminating: • No state occurs more than once in the sequence • Model M contains no executable statements when placed in the last state of the sequence • Cyclic: • All states except for the last one are distinct • Last state of the sequence is equal to one of the earlier states • Cyclic sequences define potentially infinite executions • System behavior of a PROMELA model: • Defined by all terminating and cyclic sequences generated by executing this model • Set of reachable states of a PROMELA model: • The union of all states included in the system behavior 4-1-11

  12. State Properties • Propositions • Correctness claims for PROMELA models can be built up from simple propositions • A proposition is a boolean condition on the state of the system • A proposition can refer to all the elements of a system state: • Local and global variables • Control-flow points of arbitrary executing processes • Contents of message channels • Propositions implicitly define labeling of states • In any given state, a proposition is either true or false • Correctness criteria can be expressed in terms of states in which a given proposition should hold • Specified by assertion statements in PROMELA 4-1-12

  13. Temporal Ordering of Propositions • Correctness criteria can be expressed as a temporal ordering of propositions (if more than one proposition is used) • Need to specify order in which propositions are required to hold • Truth of one proposition follows (immediately or eventually) the truth of another • Complementary way to express temporal ordering • Define the order in which propositions should never hold • Only this alternative is supported in PROMELA • Through a language feature called temporal claim 4-1-13

  14. Temporal Claims • We need to specify ordering of propositions • Semantics of proposition orderings is different from statement orderings in PROMELA • A sequential ordering implies that second statement in a process is to be executed after the first one terminates • However, in reality we cannot assume relative speed of entities • All we can say is that second statement executes eventually after the first one • Correctness claims have to be more specific • In a temporal claim, a sequential ordering of two propositions defines an immediate consequence 4-1-14

  15. Temporal Claims and Process Types • Types of correctness requirements are different for terminating and cyclic sequences • Terminating processes • An important requirement for terminating sequences is absence of deadlocks • Not all terminating sequences correspond to deadlocks • Need to express which final state properties make a terminating sequence acceptable as non-deadlocking. • Cyclic processes • Temporal claims for cyclic sequences need to express general conditions, such as absence of livelocks and non-progress cycles 4-1-15

  16. Assertions • Correctness criteria can be expressed as boolean conditions • This criteria must be satisfied whenever a process reaches a given state • PROMELA uses assert statement for this purpose • Syntax of assert statement assert(condition) • The condition can be an arbitrary boolean expression • This statement is always executable • It can be placed anywhere in a PROMELA specification • Effect of the assert statement: • If the condition is true, the statement has no effect • If condition is false in at least one execution sequence, the validity of the statement is violated • The PAN run-time flag –A can be used to disable the reporting of assertion violations • “spin –a file_name.pml” will generate a pan.c file. This file is compiled “cc –o pan pan.c” to get the executable used for verification 4-1-16

  17. Assertions: Example • In this example, we cannot predict what will be the final value of state • 0, 1, or 2 • We can try the following correctness criteria: • When process of type A completes, value of state must be 2 • When process of type B completes, value of state must be 0 • Expressed using assert • Claims are of course false! Example without assertions C:\Tools\spin>spin state.pml state in A is: 1 spin: line 2 "state.pml", Error: assertion violated spin: text of failed assertion: assert((state==2)) #processes: 3 state = 1 8: proc 2 (B) line 3 "state.pml" (state 3) 8: proc 1 (A) line 2 "state.pml" (state 4) 8: proc 0 (:init:) line 4 "state.pml" (state 3) <valid end state> 3 processes created Example with assertions 4-1-17

  18. System Invariants • System invariants are boolean conditions, such that: • If they are true in the initial system state, they remain true in all reachable system states • This is independent of the execution sequence that leads to each specific state • A more general application of assert is to formalize system invariants • System invariants can be expressed in a monitor process • Example:proctype monitor() { assert (invariant) } • This process, after it has been started with a run statement, continues to execute independently of the rest of the system • The assert statement is executable once for every system state 4-1-18

  19. #define p 0 #define v 1 chan sema[0] of { bit }; proctype dijkstra() { do :: sema!p -> sema?v od } proctype user() { sema?p; /* critical section */ sema!v /* non-critical section */ } init { atomic { run dijkstra(); run user(); run user(); run user(); } } Semaphore guarantees mutually exclusive access to critical sections We can modify the above to count the number of user processes in the critical section #define p 0 #define v 1 chan sema[0] of { bit }; byte count; proctype dijkstra() { do :: sema!p -> sema?v od } proctype user() { sema?p; count = count + 1; skip; /* critical section */ count = count – 1; sema!v skip; /* non-critical section */ } proctype monitor() { assert(count==0 || count==1) } init { atomic { run dijkstra(); run monitor(); run user(); run user(); run user(); } } System Invariants: Dijkstra’s Semaphore 4-1-19

  20. Deadlocks • Two types of possible execution sequences in a finite state system: • Either terminate after a finite number of state transitions; or • Cycle back to a previously visited state • There are two types of end states that should be distinguished: • Expected or proper end states • Unexpected end states • Error states due to incomplete or inconsistent protocol specifications • Deadlock state is only one type of possible error states • Example: unspecified receptions • Two criteria for the final state of a terminating execution sequence to be considereda properend-state: • Every instantiated process has terminated • All message channels are empty 4-1-20

  21. Deadlocks: End-State Labels • All processes do not necessarily terminate • Some processes may stay alive even after all others terminate • Example: server processes • In PROMELA, process states can be identified in proctype definitions as proper end-states using end-state labels • Exmaple: dijkstra’s algorithm: proctype dijkstra(){end: do :: sema!p -> sema?v od} • Process will be considered in a proper end-state when it is in a state labeled end 4-1-21

  22. End-State Labels (Cont’d) • More than one proper end-sate within a single proctype are possible • All label names must be unique • An end-state label is any label with prefix end • Examples: enddne, end0, endme, end_of_part_1, end_war etc. • Revised first criterion of proper end-state: • Every instantiated process has either terminated or reached a state marked as a proper end-state • Any final state in a terminating execution sequence that does not satisfy above criteria is classified as an improper end-state • An implicit correctness claim for a validation model is that the behaviors they define, do not include any improper end states • The PAN run-time flag –E can be used to suppress the reporting of invalid end states (i.e., “pan –E”) • The PAN run-time option –q means that all message channels must be empty for a system state to be considered valid (in addition to reaching a valid end state). 4-1-22

  23. Bad Cycles • Correctness requirements (i.e., properties) of cyclic sequences can be expressed in PROMELA: • Non-progress cycles • Livelocks • Two properties are: • No infinite behaviors of only unmarked states • System cannot infinitely cycle through unmarked states • Marked states are called progress-states • Execution sequences violating this correctness claim are called non-progress cycles • No infinite behaviors that include marked states • Execution sequences violating this claim are called livelocks 4-1-23

  24. Non-Progress Cycles • How to claim absence of non-progress cycles? • Define the system states within PROMELA model that represent progress • Defined through progress-state labels • A progress-state label marks a state that must be executed for the protocol to make progress • Examples: • Delivering data to a receiver • Incrementing a sequence number • Passing of a semaphore test will show “progress”proctype dijkstra(){end: do :: sema!p ->progress: sema?v od} • The passing of the semaphore guard cannot be postponed infinitely long • In all infinite executions, the semaphore process reach the progress label infinitely often • An automated validator can confirm that this claim cannot be violated • More than one progress-state labels are possible: progress0, progressing, progression etc. • Use “cc –DNP –o pan pan.c” to enable non-progress checking, and “pan -l” to search for non-progress cycles 4-1-24

  25. Livelocks • Formally expressed as something that cannot happen infinitely often • Using acceptance-state labels • An acceptance-state marks a state that may not be part of a sequence of states that can be repeated infinitely often. • An acceptance-state label start with prefix “accept” • Examples: acceptance, accepting, etc. • Example: modified proctype dijkstra():proctype dijkstra(){end: do :: sema!p ->accept: sema?v od} • Claim: it is impossible to cycle through a series of p and v operations • This claim is false 4-1-25

  26. Temporal Claims • So far, we have defined specifications of correctness criteria with: • Assertions • Three special labels to mark end, progress, and acceptance states • Temporal claims define temporal orderings of properties of states • We can express claims, such as:Every state in which property P is true is followed by a state in which property Q is true This is expressed as: P -> Q • In the above statement, “followed by” has two interpretations: • Immediately followed by; or • Eventually followed by • PROMELA support the second interpretation with the first as a special case 4-1-26

  27. Temporal Claims (Cont’d) • Two problems in specifying temporal claims P -> Q: • Temporal claims should express orderings of properties that are impossible, just like other correctness criteria • Temporal claims are defined on complete execution sequences • Even if a prefix of the sequence is irrelevant, it must be represented as a trivially true sequence of propositions • Example:never { do :: skip :: break od -> P -> !Q } • Independent of initial sequence of events, it is impossible for a state in which property P is true to be followed by a state in which property Q is false • Claim is matched if and when claim body terminates and corresponding correctness property is violated • Thus, PROMELA notation for temporal claims is:never { … } • A never claim is normally used to specify either finite or infinite system behavior that should never occur 4-1-27

  28. Example: Temporal Claims • We want to express the temporal property that condition1 can never remain true infinitely long • We need a representation of all behaviors, such that • condition1 may be false initially • It becomes true eventually • It remains true • Expressed in PROMELA as follows: never { do :: skip :: condition1 -> break od;accept: do :: condition1 od} • If and when the acceptance cycle is detected, claim is matched and corresponding correctness property is violated (livelock) 4-1-28

  29. Example: Temporal Claims (Cont’d) • Another claim (perhaps an erroneous version of previous) can be expressed as follows:never { do :: skip :: condition1 -> break od;accept: condition1} • Claim has just two state transitions after condition1 becomes true: • This claim is completely matched if there is at least one execution sequence in which condition1 holds in two subsequent states • For the first version, it would be an error (a livelock) if the machine can stay in the accept state infinitely long. • For the second version, it would be an error if the terminal state is reachable 4-1-29

  30. Specifying Temporal Claims • Body of a temporal claim is similar to a proctype body, except for one difference: • Every statement inside a temporal claim is interpreted as a condition • These should be free of side-effects • PROMELA statements with side-effects are: assignments, assertions, sends, receives, and printf statements. • A temporal claim is matched if: • An undesirable/illegal behavior can be realized • Thus, correctness claim is violated • Application of temporal claims: • Most useful ones combine temporal claims with acceptance labels • Two ways to match a temporal claim depending on undesirable behavior • Undesirable behavior can define: • A terminating sequence; or • A cyclic execution sequence (livelock) 4-1-30

  31. Specifying Temporal Claims (Cont’d) • For a terminating execution sequence, a temporal claim is matched only when it can terminate (reaches the closing curly brace) • The claim can be violated if the closing curly brace of the PROMELA body of the claim is reachable. • For a cyclic execution sequence, the claim is matched only when an explicit acceptance cycle exists. • To check a cyclic temporal claim, acceptance labels should only occur within the claim and not elsewhere in the PROMELA code. • A combination of never claim with accept labels can express the absence of non-progress cycles • Thus, temporal claims are more general than progress-state labels • However, cost (complexity) of validation with progress-state labels is smaller • There are easier ways to express never claims • Spin’s built-in translator from formulae in linear temporal logic (LTL) to never claims (less expressive than never claims) • The timeline editor, a graphical tool, converts timeline descriptions into never claims (less expressive than LTL formula) 4-1-31

  32. trace Assertion • Expresses a correctness requirement on existing behavior in the remainder of the system • Expresses properties of message channels • Formalizes statements about valid and invalid sequence of operations that processes can perform on message channels • All channel names referenced in a trace assertion must be global • All message fields must be global or mtype constants. • Example: trace { do :: q1!a; q2?b od } • Send operations on channel q1 alternate with receive operations on channel q2 • All send operations on q1 are exclusively messages of type a • All receive operations on q2 are exclusively messages of type b • Must always be deterministic • Cannot contain random receive, sorted send, or channel poll operations • No data objects can be declared or referred to inside a trace assertion • Don’t care values for specific message fields can be specified with the predefined write-only variable _ (i.e., the underscore symbol) • notrace assertion is also supported, but rarely used • Specifies a sequence of events that should not occur in an execution 4-1-32

  33. Tracing Verification Errors • When the verifier finds an error it writes a complete trace for the error execution into a file called file_name.pml.trail • Using this file, we can reproduce the error trail with spin’s guided simulation option: “spin –t –p file_name.pml” 4-1-33

More Related