- states
- a variable's state is a name-value pair
- a program's state is the state of all its variables
- not really all; usually globals, but not always
- may include hidden variables (the pc, status registers) and imaginary
or ghost variables that do not appear in the program
- a state trace (or history) is a sequence of program states
- each state is one step away from the next
- states and state traces provide an important way to specify and think
about program behavior
- focuses on the important part - the data's where it's at, after all
- abstract away much detail - what matters is where you end up, not
how you get there
- properties
- a property is a boolean statement about a program's state
- a property that is true is satisfied
- we'll use (quasi) predicate calculus to describe properties
- a property might be always true, or may eventually become true
- a safety property is an always true property
- a liveness property is an eventually true property
- a program can be characterized by a set of properties describing input
and output behaviors
- given a program specified by properties
- the program satisfies its properties if any execution of the program
leaves the properties satisfied
- axiomatic semantics
- does a particular program satisfy its properties
- debugging - there's too many traces to debug
- each trace is difficult to understand - interleaving
- the act of debugging changes the trace - stepping in the same
stream twice
- operational - this, then this, then this; too many traces again
- reason about program properties - cuts down on the work
- axiomatic reasoning about properties
- examine statements' effect on properties - the hoar triple
{pre}
s {post}
- if
pre
is true and s
executes, then post
is true
- proof outlines interleave properties and statements
- the axioms establish how each statement effects preconditions
- sequencing - if
{p} s {q}
and {q} s {r}
, then {p} s ;
s {r}
- assignment -
{p[x <- e]} x = e {p}
- if - one branch, or two
- while - the loop invariant
- consequence - strengthening and weakening
- await - like a one-branch if
- interference
- a property may contain a write critical reference - one is too
many; critical property (or assertion)
- some other step may invalidate the property - interference
- need to show noninterference -
{C and pre} s {C}
- need to show this for all other statement
s
- that's usually
a lot, but much fewer than than execution traces
- properties within atomic actions may be ignored
- the
co
statement axiom
- avoiding interference
- four techniques for avoiding interference
- disjoint variables
- no write critical reference, no interference
- usually indicates a design error - using a global when a local
would do
- you probably need other techniques too
- weaken the property
- take into account the effects of other statements
- use sparingly - properties can become huge otherwise
- use global invariants
- properties that are always true, no matter which step executes
- involves global variables
- critical assertions are a conjunction of global invariants and
properties over local variables and uniquely written globals
- this is an important technique for structuring and reasoning about
concurrent programs - reasoning in isolation
- use synchronization
- properties within atomic actions are not critical
- hide properties within atomic actions - granularity
- delay the conflicting statement until the critical assertion is
false or can be made true by executing the statement
This page last modified on 16 June 2002.