Checking correctness properties of object-oriented programs

1
Checking correctness properties of
object-oriented programs

• K. Rustan M. LeinoMicrosoft Research, Redmond, WA

Lecture 4EEF summer school on Specification,
Refinement, and Verification23 Aug 2002, Turku,
Finland
2
Programming methodology

• Restricts programs by imposing a programming
  discipline
• Can simplify concepts involved in reasoning about
  programs
• Not always a match for all good programs,
  because
• the methodology may not be adequately formalized,
  and
• programming methodologies evolve

3
Valid/state paradigm
class T abstract field valid bool abstract
field state unit constructor T(this, x, y,
z) requires P(x,y,z) modifies this.valid,
this.state ensures this.valid method
operation0(this, x, y, z) requires this.valid
/\ R0(x,y,z) modifies this.state ensures
true method operation1(this, x, y, z) requires
this.valid /\ R1(x,y,z) modifies this.state
ensures true field f int in valid,
state field g int in valid, state field h int
in state rep this.valid ? this.f lt this.g
4
The role of valid
class T abstract field valid bool abstract
field state unit constructor T(this, x, y,
z) requires P(x,y,z) modifies this.valid,
this.state ensures this.valid method
operation0(this, x, y, z) requires this.valid
/\ R0(x,y,z) modifies this.state ensures
true method operation1(this, x, y, z) requires
this.valid /\ R1(x,y,z) modifies this.state
ensures true field f int in valid,
state field g int in valid, state field h int
in state rep this.valid ? this.f lt this.g
5
Object invariants
class T abstract field state
unit constructor T(this, x, y, z) requires
P(x,y,z) modifies this.state ensures true method
operation0(this, x, y, z) requires R0(x,y,z)
modifies this.state ensures true method
operation1(this, x, y, z) requires R1(x,y,z)
modifies this.state ensures true field f int
in state field g int in state field h int in
state invariant this.f lt this.g
Methodology an object invariant always holds
6
When should invariants hold?
class T field x, y, z int invariant this.x
this.y this.z
On procedure boundaries
7
Which procedure boundaries?
class T field v Vector field w Vector
invariant this.v.size this.w.size method
check(this) assert this.v.size this.w.size
method m(this) this.v.extend(E)
this.w.extend(F) class Vector abstract
field size int method extend(this,
x) requires true modifies this.size ensures
this.size this.size0 1
8
Which procedure boundaries?
class T field v Vector field w Vector
invariant this.v.size this.w.size method
check(this) assert this.v.size this.w.size
method m(this) this.v.extend(E)
this.w.extend(this) class Vector abstract
field size int method extend(this,
x) requires true modifies this.size ensures
this.size this.size0 1 mimpl extend(this, x)
x.check()
9
Constructors
class T lt S field x int field y int
invariant this.x this.y constructor T(this,
a int, b int) this.S() if a b
then this.x a this.y b else this.x
b this.y a end this.p() method
p(this) requires true modifies e ensures true
10
Constructors a further subclass
class U lt T field m int field n int
invariant this.m lt this.n constructor U(this)
this.T(12, 6) this.m 20 this.n
21 mimpl p(this) assert this.m lt
this.n
11
Close methods
class T abstract field valid bool abstract
field state unit constructor T(this) requires
true modifies this.valid, this.state ensures
this.valid method m(this) requires this.valid
modifies this.state ensures true method
close(this) requires this.valid modifies
this.valid, this.state ensures true var t
in t new(T) t.m() t.close() t.m() //
errorend
12
The role of state
class T abstract field state
unit constructor T(this, x, y, z) requires
P(x,y,z) modifies this.state ensures true method
operation0(this, x, y, z) requires R0(x,y,z)
modifies this.state ensures true method
operation1(this, x, y, z) requires R1(x,y,z)
modifies this.state ensures true field f int
in state field g int in state field h int in
state invariant this.f lt this.g
Can state be hidden?
13
Summary invariants

• simple concept
• tricky to get rules right
• language designers beware design constructors
  carefully!
• does not (alone) handle close methods
• requires more research

14
Concurrency

• Multiple threads running in parallel, reading and
  writing shared data
• Mutual exclusion provided by mutexes (locks) var
  mu Mutex lock mu do // acquire
  mu S end // release mu

15
Concurrency race conditions

• A race condition occurs when a shared variable is
  written by one thread and concurrently read or
  written by another thread

16
Avoid race conditions

• Methodology Every shared variable is protected
  by some declared mutex
• var mu Mutexvar x monitored_by mu
• lock mu do x end

17
Concurrency deadlocks

• A deadlock occurs when a set of threads each
  waits for a mutex that another thread holds

18
Avoiding deadlocks

• Methodology
• partially order the mutexes
• in each thread, acquire mutexes in ascending order

var mu0 Mutexvar mu1 Mutexdeclare mu0 lt
mu1 lock mu1 do lock mu0 do //
error endend
19
Updating mutexes
var mu Mutexvar x monitored_by mu
Thread 1 mu new(Mutex)lock mu do x Fend
Thread 0 lock mu do x Eend
20
Monitor state
var mu Mutexvar x monitored_by mu lock mu
do x 10endlock mu do assert x 10 //
errorend
havoc x
21
Changing the order
class Node field x monitored_by this field
left Node field right Node declare this lt
this.left declare this lt this.right method
balance(this)
22
Summary concurrency

• simple ideas
• methodology allows for sequential reasoning
• tricky in dynamic situations
• needs more research

23
Summary

• Semantic checkers for object-oriented languages
  are possible
• Methodology requires more work

24
References

• David L. Detlefs, K. Rustan M. Leino, Greg
  Nelson, and James B. Saxe. Extended static
  checking. Research Report 159, Compaq SRC, Dec.
  1998.
• K. Rustan M. Leino and Greg Nelson. Data
  abstraction and information hiding. Research
  Report 160, Compaq SRC, Nov. 2000. To appear in
  TOPLAS.
• Bertrand Meyer. Object-oriented Software
  Construction. International Series in Computer
  Science, Prentice Hall, 1988.
• K. Rustan M. Leino and Raymie Stata. Checking
  object invariants. Technical Note 1997-007, DEC
  SRC, Jan. 1997.
• K. Rustan M. Leino, Greg Nelson, and James B.
  Saxe. ESC/Java Users Manual. Technical Note
  2000-002, Compaq SRC, Oct. 2000.
• Cormac Flanagan, K. Rustan M. Leino, Mark
  Lillibridge, Greg Nelson, James B. Saxe, and
  Raymie Stata. Extended static checking for
  Java. In PLDI 02, SIGPLAN Notices 37(5), pp.
  234-245, ACM, May 2002.

25
References

• Gary T. Leavens, Albert L. Baker, and Clyde Ruby.
  Preliminary Design of JML A Behavioral
  Interface Specification Language for Java.
  Department of Computer Science, Iowa State
  University, TR 98-06r, Aug. 2002.
• K. Rustan M. Leino. A myth in the modular
  specification of programs. Unpublished
  manuscript KRML 63, DEC SRC, Nov. 1995.
  Available from author.
• C.A.R. Hoare. Monitors an operating system
  structuring concept. CACM 17(10), pp. 549-557,
  ACM, Oct. 1974.