Transcript oopsla_2009_src.ppt

Modular Typestate Checking for
Concurrent Java Programs
Nels E. Beckman
Carnegie Mellon University
(Advised by Jonathan Aldrich)
Problem: Check-then-Act Races
void
pass()
{
class
OnePlaceBuffer<T>
{
final
OnePlaceBuffer<String>
b = new OnePlaceBuffer<String>();
T item
= null;
b.put("Welcome
to OOPSLA!");
public synchronized
boolean isFull() {...}
shareWithNewThread(b);
public synchronized void put(T item) {...}
if( b.isFull() )
public
synchronized T get() {
print(b.get());
}
if(item==null) throw new Empty();
T result = item;
void shareWithNewThread(OnePlaceBuffer<String>
b) {
new item
Thread()
{
= null;
if( b.isFull() )
print(b.get());
return
result;
}.start();
}
}
}
2
Approach: Specification & Access
Permissions
1. Programmers define abstract states &
transitions
–
(Implicitly with PRE- and POST-conditions)
2. Specifications also include access permissions
–
–
Describe aliasing, approximates thread sharing
Checked for consistency
3. Statically track states of refs to objects that
cannot be concurrently modified
4. If mutual exclusion is used, temporarily track
states of refs to object that can be
3
1 – Define Protocol via Specification
class OnePlaceBuffer<T> {
@Spec(ensures=“EMPTY”)
public OnePlaceBuffer(){…}
@TrueIndicates(“FULL”)
@FalseIndicates(“EMPTY”)
public synchronized boolean isFull() {…}
@Spec(requires=“EMPTY”,ensures=“FULL”)
public synchronized void put(T item) {…}
@Spec(requires=“FULL”, ensures=“EMPTY”)
public synchronized T get() {…}
}
4
2 – Access Permissions
• Static information, specified for each reference, tracked
by analysis
–
–
–
–
Does reference point to aliased object?
Does ref. have the right to modify? Do other refs.?
Approximates thread-sharedness
Five different kinds of permission
unique(ref) – “At runtime, ref will be the only reference pointing to the object.”
immutable(ref) – “ref points to an aliased object, but no reference can modify it.”
full(ref) – “ref points to an aliased object, that will only be modified through ref.”
pure(ref) – “ref points to an aliased object, that it cannot be used to modify. Other
modifying references may exist!”
share(ref) – “ref points to an aliased object and can be used to modify that object.
Other modifying references may exist!”
5
2 – Adding Access Permissions to Spec.
class OnePlaceBuffer<T> {
@Unique(ensures=“EMPTY”)
public OnePlaceBuffer(){…}
@Pure
@TrueIndicates(“FULL”)
@FalseIndicates(“EMPTY”)
synchronized boolean isFull() {…}
void pass() {
final OnePlaceBuffer<String> b =
new OnePlaceBuffer<String>();
b.put("Welcome to OOPSLA!");
shareWithNewThread(b);
if( b.isFull() )
print(b.get());
}
@Share(requires=“EMPTY”,
ensures=“FULL”)
synchronized void put(T item) {…}
@Share(requires=“FULL”,
ensures=“EMPTY”)
public synchronized T get() {…}
}
void shareWithNewThread(
@Share(returned=“false”)
OnePlaceBuffer<String> b) {
new Thread() {
if( b.isFull() )
print(b.get());
}.start();
}
6
3 – Tracking States on References
void shareWithNewThread(
@Share(returned=“false”)
Recall:
OnePlaceBuffer<String>
b) {
share(ref) – “ref points to an aliased object and can be
new Thread() used
{ to modify that object. Other modifying references
may exist!”
// Context: share(b) in ?
Assuming)that other refs are reachable from other
if( b.isFull()
threads…
// Context: share(b) in ?
We must assume concurrent modification!
print(b.get());
// ERROR
}.start();
}
7
4 – Using Mutual Exclusion
void shareWithNewThread(
@Share(returned=“false”)
OnePlaceBuffer<String> b) {
new Thread() {
synchronized(b) {
// Context: share(b) in ?
if( b.isFull() )
// Context: share(b) in FULL
print(b.get());
// Context: share(b) in EMPTY
}
}.start();
}
8
Not Covered in this Talk…
• Verification of Implementation
– Ensures correct synchronization internally
• Rules for Subtyping
– Ensuring that subtype specs are compatible
• Dimensions
– Allow states and permissions to reference sub-sets of an
object
• State Hierarchies
– Hierarchical state refinement
• Fractions
– Allow weaker permissions (e.g., share) to be statically
combined to form stronger permissions (e.g., unique)
9
Related Work
• Fractional Permissions
– Boyland
• Ownership Types
– Jacobs et al
• Concurrent Separation Logic
– O’Hearn
• Single-threaded permissions
– Bierhoff et al
– (Unsound in multi-threaded programs)
10
Contributions
• Going beyond static data race detection
– Preventing application-specific, check-then-act
races
• Extends single-threaded work with no
additional specification burden
• For S.R.C.
– Extended approach to support synchronized
blocks
11