Modular Typestate Checking for Concurrent Java Programs Nels E. Beckman Carnegie Mellon University (Advised by Jonathan Aldrich)

Problem: Check-then-Act Races class OnePlaceBuffer { T item = null; public synchronized boolean isFull() {...} public synchronized void put(T item) {...} public synchronized T get() { if(item==null) throw new Empty(); T result = item; item = null; return result; } 2 void pass() { final OnePlaceBuffer b = new OnePlaceBuffer (); b.put("Welcome to OOPSLA!"); shareWithNewThread(b); if( b.isFull() ) print(b.get()); } void shareWithNewThread(OnePlaceBuffer b) { new Thread() { if( b.isFull() ) print(b.get()); }.start(); }

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 4 class OnePlaceBuffer public synchronized boolean isFull() public synchronized void put(T item) ensures=“EMPTY”) public synchronized T get() {…} }

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 5 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!”

2 – Adding Access Permissions to Spec. class OnePlaceBuffer @FalseIndicates(“EMPTY”) synchronized boolean isFull() ensures=“FULL”) synchronized void put(T item) ensures=“EMPTY”) public synchronized T get() {…} } void pass() { final OnePlaceBuffer b = new OnePlaceBuffer (); b.put("Welcome to OOPSLA!"); shareWithNewThread(b); if( b.isFull() ) print(b.get()); } void OnePlaceBuffer b) { new Thread() { if( b.isFull() ) print(b.get()); }.start(); } 6

3 – Tracking States on References void OnePlaceBuffer b) { new Thread() { // Context: share(b) in ? if( b.isFull() ) // Context: share(b) in ? print(b.get()); }.start(); } 7 Recall: share(ref) – “ref points to an aliased object and can be used to modify that object. Other modifying references may exist!” Assuming that other refs are reachable from other threads… We must assume concurrent modification! // ERROR

4 – Using Mutual Exclusion void OnePlaceBuffer 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