Upload
alyssa-roberts
View
215
Download
1
Tags:
Embed Size (px)
Citation preview
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.