Checking correctness properties of object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 4 EEF summer school on Specification,

Checking correctness Checking correctness properties of object-oriented properties of object-oriented

programsprograms

K. Rustan M. LeinoK. Rustan M. LeinoMicrosoft Research, Redmond, WAMicrosoft Research, Redmond, WA

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

Programming methodologyProgramming methodology Restricts programs by imposing a Restricts programs by imposing a

programming disciplineprogramming discipline Can simplify concepts involved in Can simplify concepts involved in

reasoning about programsreasoning about programs Not always a match for all good Not always a match for all good

programs, because:programs, because: the methodology may not be adequately the methodology may not be adequately

formalized, andformalized, and programming methodologies evolveprogramming methodologies evolve

Valid/state paradigmValid/state paradigmclass T {

abstract field valid: boolabstract 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

truemethod operation1(this, x, y, z)

requires this.valid /\ R1(x,y,z) modifies this.state ensures true

…field f: int in valid, statefield g: int in valid, statefield h: int in state

rep this.valid this.f < this.g

… }

The role of validThe role of validclass T {

abstract field valid: boolabstract 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

truemethod operation1(this, x, y, z)

requires this.valid /\ R1(x,y,z) modifies this.state ensures true

…field f: int in valid, statefield g: int in valid, statefield h: int in state

rep this.valid this.f < this.g

… }

Object invariantsObject invariantsclass 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 statefield g: int in statefield h: int in state

invariant this.f < this.g

… }

Methodology: an object invariant “always” holds

When should invariants When should invariants hold?hold?

class T {field x, y, z: intinvariant this.x = this.y + this.z

…

}

On procedure boundariesOn procedure boundaries

Which procedure Which procedure boundaries?boundaries?class T {

field v: Vectorfield 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: intmethod extend(this, x)

requires true modifies this.size ensures this.size = this.size0 + 1}

Which procedure Which procedure boundaries?boundaries?class T {

field v: Vectorfield 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: intmethod extend(this, x)

requires true modifies this.size ensures this.size = this.size0 + 1

mimpl extend(this, x) {x.check();…

}}

ConstructorsConstructorsclass T <: S {

field x: intfield 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 := belse

this.x := b; this.y := aend;this.p()

}

method p(this) requires true modifies ε ensures true}

Constructors: a further Constructors: a further subclasssubclassclass U <: T {

field m: intfield n: int invariant this.m < this.n

constructor U(this) {this.T(12, 6);this.m := 20;this.n := 21

}

mimpl p(this) {assert this.m < this.n

}}

Close methodsClose methodsclass T {

abstract field valid: boolabstract 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() // error

end

The role of stateThe role of stateclass 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 statefield g: int in statefield h: int in state

invariant this.f < this.g

…}

Can state be “hidden”?Can state be “hidden”?

Summary: invariantsSummary: invariants simple conceptsimple concept tricky to get rules righttricky to get rules right language designers beware: design language designers beware: design

constructors carefully!constructors carefully! does not (alone) handle close does not (alone) handle close

methodsmethods requires more researchrequires more research

ConcurrencyConcurrency Multiple threads running in parallel, Multiple threads running in parallel,

reading and writing shared datareading and writing shared data Mutual exclusion provided by Mutual exclusion provided by

mutexes (locks)mutexes (locks)varvar mu: Mutex mu: Mutex……locklock mu mu dodo // acquire mu// acquire mu

SSendend // release mu// release mu

Concurrency: race Concurrency: race conditionsconditions

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

Avoid race conditionsAvoid race conditions Methodology: Every shared variable Methodology: Every shared variable

is protected by some declared mutexis protected by some declared mutex

varvar mu: Mutex mu: Mutexvarvar x x monitored_bymonitored_by mu mu

locklock mu mu dodo… x …… x …

endend

Concurrency: deadlocksConcurrency: deadlocks A A deadlockdeadlock occurs when a set of occurs when a set of

threads each waits for a mutex that threads each waits for a mutex that another thread holdsanother thread holds

Avoiding deadlocksAvoiding deadlocks Methodology:Methodology:

partially order the mutexespartially order the mutexes in each thread, acquire mutexes in in each thread, acquire mutexes in

ascending orderascending ordervar mu0: Mutexvar mu1: Mutexdeclare mu0 < mu1

…

lock mu1 dolock mu0 do // error

…end

end

Updating mutexesUpdating mutexesvar mu: Mutexvar x monitored_by mu

Thread 0:

lock mu dox := E

end

Thread 1:

mu := new(Mutex);lock mu do

x := Fend

Monitor stateMonitor statevar mu: Mutexvar x monitored_by mu

…

lock mu dox := 10

end;lock mu do

assert x = 10 // errorend

havoc x;

Changing the orderChanging the order

class Node {field x monitored_by this;field left: Nodefield right: Nodedeclare this < this.leftdeclare this < this.right

method balance(this) …

Summary: concurrencySummary: concurrency simple ideassimple ideas methodology allows for sequential methodology allows for sequential

reasoningreasoning tricky in dynamic situationstricky in dynamic situations needs more researchneeds more research

SummarySummary Semantic checkers for object-Semantic checkers for object-

oriented languages are possibleoriented languages are possible Methodology requires more workMethodology requires more work

ReferencesReferences David L. Detlefs, K. Rustan M. Leino, Greg Nelson, and James B. David L. Detlefs, K. Rustan M. Leino, Greg Nelson, and James B.

Saxe. Saxe. Extended static checkingExtended static checking. Research Report 159, Compaq . Research Report 159, Compaq SRC, Dec. 1998.SRC, Dec. 1998.

K. Rustan M. Leino and Greg Nelson. K. Rustan M. Leino and Greg Nelson. Data abstraction and Data abstraction and information hidinginformation hiding. Research Report 160, Compaq SRC, Nov. . Research Report 160, Compaq SRC, Nov. 2000. To appear in 2000. To appear in TOPLASTOPLAS..

Bertrand Meyer. Bertrand Meyer. Object-oriented Software ConstructionObject-oriented Software Construction. . International Series in Computer Science, Prentice Hall, 1988.International Series in Computer Science, Prentice Hall, 1988.

K. Rustan M. Leino and Raymie Stata. K. Rustan M. Leino and Raymie Stata. Checking object Checking object invariantsinvariants. Technical Note 1997-007, DEC SRC, Jan. 1997.. Technical Note 1997-007, DEC SRC, Jan. 1997.

K. Rustan M. Leino, Greg Nelson, and James B. Saxe. K. Rustan M. Leino, Greg Nelson, and James B. Saxe. ESC/Java ESC/Java User’s ManualUser’s Manual. Technical Note 2000-002, Compaq SRC, Oct. . Technical Note 2000-002, Compaq SRC, Oct. 2000.2000.

Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, and Raymie Stata. “Extended static Nelson, James B. Saxe, and Raymie Stata. “Extended static checking for Java”. In checking for Java”. In PLDI ’02PLDI ’02, SIGPLAN Notices 37(5), pp. 234-, SIGPLAN Notices 37(5), pp. 234-245, ACM, May 2002.245, ACM, May 2002.

ReferencesReferences Gary T. Leavens, Albert L. Baker, and Clyde Ruby. Gary T. Leavens, Albert L. Baker, and Clyde Ruby.

Preliminary Design of JML: A Behavioral Interface Preliminary Design of JML: A Behavioral Interface Specification Language for JavaSpecification Language for Java. Department of Computer . Department of Computer Science, Iowa State University, TR #98-06r, Aug. 2002.Science, Iowa State University, TR #98-06r, Aug. 2002.

K. Rustan M. Leino. “A myth in the modular specification of K. Rustan M. Leino. “A myth in the modular specification of programs”. Unpublished manuscript KRML 63, DEC SRC, programs”. Unpublished manuscript KRML 63, DEC SRC, Nov. 1995. Available from author.Nov. 1995. Available from author.

C.A.R. Hoare. “Monitors: an operating system structuring C.A.R. Hoare. “Monitors: an operating system structuring concept”. concept”. CACMCACM 17(10), pp. 549-557, ACM, Oct. 1974. 17(10), pp. 549-557, ACM, Oct. 1974.