types for atomicity authors: cormac flanagan, uc santa cruz stephen freund, marina lifshin, williams...

Types for Atomicity

Authors:Cormac Flanagan, UC Santa CruzStephen Freund, Marina Lifshin, Williams CollegeShaz Qadeer, Microsoft Research

Presentation by Anton Wolkov for Seminar in Distributed Algorithms Spring 2013

Subject of this paper

A way to simplify verification of programs with arbitrarily-interleaved threads accessing common resources by introducing an extension to the Java type system with special notations.

The notation writing task itself is simplified by introducing special type inference system.

Finally using a prototype checker on benchmark code we show the usefulness of this type system.

What problems are we addressing?

Multi-threaded Java programs are hard to verify manually, because they can misbehave when non atomic operations with write operations on common resources are interleaved in unexpected ways.

Even existing Java libraries exhibit subtle flaws after years of community and internal QA.

We would much rather manually verify a serial execution of a multi-threaded program.

Race Conditions

What is a race condition?

A race condition occurs when two threads simultaneously access the same data variable, and at least one of the accesses is a write.

A lot of work has been done in detecting these types of flaws with static and dynamic analysis and there are decent tools for detecting these errors in Java.

Current solutions to race condition

There are methods and tools to detect race conditions in multi-threaded Java applications

Is a race condition free program good enough?

Is there a serial execution equivalent with the same result as any other interleaved execution?

1 C. Flanagan and S. Freund. Type-based race detection for Java. In Proceedings of the Conference on Programming Language Design and Implementation, pages 219–232, 2000.

Race Condition (2)

Is a race condition free program good enough?

No. For example:

acquire(l); t := x; release(l);t := t + 1;acquire(l); x := t; release(l);

This code by definition is race condition free.



Race Condition (3)

acquire(l); t := x; release(l);t := t + 1;acquire(l); x := t; release(l);

If this code is executed 5 times with random thread interleaving the value of x can be incremented by any value between 1 and 5.

What we would like to use is a stronger term we call atomicity.



Introducing Atomicity

Obviously we do not require the entire program to be serially executed in a multi-threaded environment, so instead we would like to have some individual methods to be safe and atomic.

What is atomicity?

A method is atomic if, for every execution, there is an equivalent serial execution in which the actions of the method are not interleaved with actions of other threads.

Introducing Atomicity Cont'd.

Thread scheduler is still free to interleave but, any interaction between threads are benign or has negative affect (access to common resources is "safe").

In layman's terms

If a method is atomic we can assume that even if it will interleaved with other code it will still act the same way it would in a serial execution.

This covers race conditions but provides a stronger guarantee.

Atomic

Race Condition

Free

Motivation for atomicity

What is it good for?

• Multi-threaded applications are prevalent.

• Thread interleavings are really hard for programmers. Flaws are commonly missed during development and code reviews.

• Previous efforts were invested in avoiding race conditions, but race condition free programs still may fail spectacularly in edge cases.

An example

class Account {

int balance = 0;

synchronized int read() {

return balance;

}

synchronized void set(int b) {

balance = b;

}

void deposit (int amount) {

int b = read();

set(b + amount);

}

}

An example

class Account {

int balance = 0;


return balance;

}


balance = b;

}


int b = read();

set(b + amount);

}

}

If a new thread comes along and modifies balance here we will set the new balance to a wrong value.

An example

class Account {

int balance = 0;


return balance;

}


balance = b;

}


int b = read();

set(b + amount);

}

}

This is not a race condition since we do not access balance concurrently.

Synchronized vs. Atomic

The synchronized keyword in java is too restrictive.

• An object wide statement, does not handle escapes.

• Too harsh. All other synchronized methods in the object are stopped from executing (serial execution).

• We would like the same bottom line without sacrificing thread interleaving completely.

Why a type system?

Programs are large, and we don't want to check it whole.

Type system provides modularity for the checker.

We also want to guarantee our libraries are safe for any use.

Verification using keywords

We introduce a formal multi-threaded subset of Java language we call AtomicJava.

Each atomic method should be notated with the keyword atomic and an appropriate level of atomicity, including the conditions are locks that are in place.

Quick Reminder:Theory of right and left movers

An action a is a right mover if for any execution where the action a performed by one thread is immediately followed by an action b of a different thread, the actions a and b can be swapped without changing the resulting state S3.

Theory of right and left movers

Similarly, an action b is a left mover if whenever b immediately follows an action a of a different thread, the actions a and b can be swapped, again without changing the resulting state.

Example of an atomic method

synchronized void inc() {int t = x;x = t + 1;

}

The keyword synchronized instructs Java to hold a lock on this for the duration of the method.

Example of anatomic method

We denote the acquisition of the lock acq and rel for the release.

Suppose that the actions of this method are

interleaved with arbitrary actions X1, X2, and

X3 of other threads

synchronized void inc() { int t = x; x = t + 1; }

Example of anatomic method

Because the acq operation is a right mover and the write and rel operations are left movers, there exists an equivalent serial execution where the operations of the method are not interleaved with operations of other threads (see illustration above). Thus the method is atomic.

synchronized void inc() { int t = x; x = t + 1; }

Theory of right and left movers cont.

• a lock-acquire operation is a right mover

• a lock-release operation is a left mover

If a variable must be held by a lock to be accessed the operation has (both) right and left movers.

In Java this is true to all synchronized methods since it does both lock-acquire and lock-release operations.

In short we will call right and left movers - movers.

Theory of right and left movers cont.

More generally, suppose a method contains a sequence of right movers followed by a single atomic action followed by a sequence of left movers. Then an execution where this method has been fully executed can be reduced to another execution with the same resulting state here the method is executed serially without any interleaved actions by other threads. Therefore, an atomic annotation on such a method is valid.

AtomicJava

We base our formal development on the language AtomicJava, a multi-threaded subset of Java with a type system for atomicity.

AtomicJava keywords

Each field declaration includes a field guard g that specifies the synchronization discipline for that field. The possible guards are:

• final - the field cannot be written to after initialization

• guarded_by l - the lock denoted by the lock expression l must be held on all accesses (reads or writes) of that field

• write_guarded_by l - the lock denoted by the lock expression l must be held on all writes of that field, but not for reads.

• no_guard - the field can be read or written at any time. Useful to denote fields with intentional race conditions.

AtomicJava parameterized classes

class cn<ghost x1,...,xn> { ... }

Classes now have a binding for the ghost

variables x1...xn, which can be referred to

from type annotations within the class body.

The type cn<l1,...,ln> refers to an instantiated

version of cn where each xi in the body is

replaced by the lock expression li.

AtomicJava parameterized methods

atomicity type method cn<ghost x1,...,xn>

(t1 y1 t2 y2 ... tm ym) { ... }

Defines a method method of return type type that is parameterized by a ghost locks x1...xn

and takes arguments of types t1...tm with

corresponding values y1...ym .

atomicity is a keyword (like atomic) which we will define next.

AtomicJava parameterized methods

atomicity type method cn<ghost x1,...,xn>

(t1 y1 t2 y2 ... tm ym) { ... }

Here, we note that the atomicity a may refer to program variables in scope, including this, the ghost parameters of the containing class, and normal parameters of the method itself.

AtomicJava synchronized methods

sync l { ... }

Acquires lock l, execute the expression inside, and finally release lock l.

This is similar to synchronized in "regular" Java only here we get to specify the lock (and synchronized always chooses this).

A forked thread does not inherit locks held by its parent thread.

AtomicJava fork

e.fork

Starts a new thread starting with (object) e's run method with a single ghost parameter.

The fork operation spawns a new thread that, conceptually, acquires a new thread-local lock tll for instantiating the ghost parameter to the method run. This lock is always held by the new thread and may therefore be used by run to guard thread-local data, and it may be passed as a ghost parameter to other methods that access thread-local data.

AtomicJava - everything else

Other expressions in the language include field read and update, method calls, variable binding and reference, conditionals, loops, and synchronized blocks. We include basic types for both single-wordints and double-wordlongs.

Only reads and writes of the former are atomic. Reads and writes of object references are also atomic.

Types of Atomicity - Levels

• consto The atomicity const describes any expression whose

evaluation does not depend on or change any mutable state. Hence the repeated evaluation of a const expression with a given environment always yields the same result.

o i.e. a method returns a constant.

• mover

• atomic

• cmpd

• error


• const

• movero The atomicity mover describes any expression that

both left and right commutes with operations of other threads.

o i.e. if access to a field f declared as guarded_by l and the access is performed with the lock l held.

• atomic

• cmpd

• error


• const

• mover

• atomico The atomicity atomic describes any expression that

is a single atomic action, or that can be considered to execute without interleaved actions of other threads

• cmpd

• error


• const

• mover

• atomic

• cmpdo The atomicity cmpd describes compound expression

for which none of the preceding atomicities apply.o i.e. sequential atomic ops not guarded by a lock

• error


• const

• mover

• atomic

• cmpd

• erroro The atomicity error describes any expression

violating the locking discipline specified by the type annotations.

Hierarchy of basic atomicity

const mover atomic cmpd error⊏ ⊏ ⊏ ⊏

Sequential composition operations of atomicity levels

; (as in b;c) denotes sequential composition

Conditional atomicity

In some cases, the atomicity of an expression depends on the locks held by the thread evaluating that expression.

For instance, if we hold lock1 we have a mover, otherwise we have a problem.

Formal notation: (lock1 ? mover : error)

A conditional atomicity (l ? a1 : a2) is equivalent to atomicity a1 if the lock l is currently held, and it is equivalent to a2 if the lock is not held.

Atomicity - Formal definition

Each atomicity level can be basic or condition:

Atomicity closure

For example:

Meaning: if lock l1 is held we have a mover, if lock l2 is held but not l1 we have an atomic op, otherwise we have a violation of thread safety.

Atomicity levels formal notation

Let b;c denote the sequential composition of b and later c

Let b* denote the iterative closure of b.

Let denote the join operator based on this ⨆subatomicity ordering. If basic atomicities b1 and b2 reflect the behavior of e1 and e2 respectively, then the nondeterministic choice between executing either e1 or e2 has atomicity b1⨆b2.

Conditional atomicity with lock sets

We denote (|b|)(ls) = b where b is a conditional atomicity and ls is a set of locks, to be equivalent to:

b = l ? a1 : a2

Meaning: for every lock in the set our atomicity is a1 and a2 for every lock that is not.

Atomicity levels calculus

Extension of iterative closure, sequential composition, and join operations to conditional atomicities

Theorem 1

Extension of iterative closure, sequential composition, and join operations to conditional atomicities with lock sets

(|a1*|)(ls)=((|a1|)(ls))*

(|a1;a2|)(ls)=(|a1|)(ls);(|a2|)(ls)

(|a1⨆a2|)=(|a1|)(ls) (|⨆ a2|)(ls)

Conditional subatomicity ordering

We now extend the subatomicity ordering to conditional atomicities.

Assume h is a set of locks held by the current thread and n is a set of locks not held by the current thread.

Intuitively, the condition a1⊑nh a2 holds if and only

if (|a1*|)(ls) (|⊑ a2

*|)(ls) holds for every lockset ls that contains h and is disjoint from n.

Conditional sub-atomicity ordering

Formally, we define a1⊑ a2 to be a1⊑∅ ∅ a and

check recursively:

The condition a1⊑nh a2 holds if and

only if (|a1*|)(ls) (|⊑ a2

*|)(ls) holds for every lockset ls that contains h and is disjoint from n.

Theorem 2

For all atomicities a1 and a2:

a1⊑ a2 ⇔ ∀ ls: (|a1|)(ls) (|⊑ a2|)(ls)

If a1, a2 are not conditional this is trivial because

∀ ls: (|a|)(ls) = a and a is non conditional

Atomicity Equivalent

Atomicities a1 and a2 are equivalent (a1≡a2) if a1⊑ a2 and a2⊑ a1 and thus:

a1≡a2 ⇔ ∀ ls: (|a1|)(ls)≡(|a2|)(ls)

Figure III

Figure IV

List Exampleclass ListElem <ghost x> {

int num guarded_by x;ListElem<x> next guarded_by x;

(x ? mover : error) int get() { return this.num; }}class List {

ListElem<this> elems guarded_by this;(this ? mover : atomic) void add (int v) {

sync (this) {this.elems = new ListElem<this>(v, this.elems);

}}atomic void addPair(int i, int j) {

this.add(i);this.add(j);

}(this ? mover : atomic) int get() {

sync (this) {return this.elems.get();

}}

}

const mover atomic cmpd ⊏ ⊏ ⊏ ⊏error



(x ? mover : error) int get() { return this.num; }}

num and next are guarded by lock x (external to the class).

If x is not held get() is an error, otherwise it's a mover as it's return value may vary depending on it's position in concurrent threads.











}}

}


get() is synchronized (holds this for the duration of the method) which makes it atomic, if this is already held we can upgrade it to a mover.

List Example - What's wrong?class ListElem <ghost x> {









}}

}


List Example Correctedclass ListElem <ghost x> {





}}(this ? mover : cmpd) void addPair(int i, int j) {

this.add(i); // (this ? mover : atomic) ;this.add(j); // (this ? mover : atomic)this.add(j); // = (this ? mover : atomic;atomic)this.add(j); // = (this ? mover : cmpd)



}}

}


Manual Annotation

The authors manually annotated parts of the JDK and then ran a prototype verifier.

Actual Findings

In JDK 1.4.0 StringBuffer's methods are documented to be atomic.

StringBuffer uses lock based synchronization to achieve atomicity.

Using a prototype checker that supports the full functionalities of Java including inheritance we found a failed atomicity type check in the method append(StringBuffer sb).

The method calls tosb.length() and sb.getChars(...) - both specified to have atomicity atomic, making the overall atomicity be cmpd.

More findings - java.lang.String

This defect was fixed in the 1.4.2 release by having contentEquals(StringBuffer sb) acquire the lock on sb for the duration of the method call.

False positives

The method String.hashCode() is also not atomic because it caches the hashcode for the String object in an unprotected field.

However, this can only result in redundant hash recomputations and not erroneous behavior.

Analysis techniques that abstract away benign atomicity violations can eliminate some spurious warnings like this one.

More findings - java.lang.Vector

interface Collection {

/*# this ? mover : atomic */ int size();

/*# this ? mover : atomic */ Object[] toArray(Object a[]);

}

class Vector ... {

Object elementData[] /*# guarded by this */;

int elementCount /*# guarded by this */;

// does not type check:

/*# atomic */ Vector(Collection c) {

elementCount = c.size();

elementData = new Object[Math.min((elementCount*110L)/100,

Integer.MAX VALUE)];

c.toArray(elementData);

}

...

}

More findings - java.lang.Vector

The Vector constructor should set elementCount to the size of its argument c and copy the contents of c into the newly-created array elementData. However, since the lock c is not held between the calls to c.size() and c.toArray(...), another thread could concurrently modify c, resulting either in an improperly initialized Vector or an ArrayIndexOutOfBounds exception.

More findings - java.lang.Vector #2public class Vector ... {

/*# this ? mover : atomic */

public void synchronized removeElementAt(int index) { ... }


public int indexOf(Object elem) { ... }

...


public synchronized boolean removeElement(Object obj) {

...

int i = indexOf(obj);

if (i >= 0) {

removeElementAt(i);

return true;

}

return false;

}

}

public abstract class Writer {// The object used to

synchronize

// operations on this stream.

protected Object lock;

Writer() {

this.lock = this;}

/*# lock ? mover : atomic */

public void write(int ch) { ... }

/*# lock ? mover : atomic */

public void write(String str) { ... }

...

}

// Does not type check!

public class PrintWriter extends Writer {

protected Writer out;

public PrintWriter(Writer out) { super(); this.out = out; }

public void print(int x) {

synchronized (lock) {

out.write(Integer.toString(x));

}

}

public void println() {


out.write(lineSeparator);

}

}

public void println(int x) {


print(x);

println();

}

}

out.lock ? (lock ? mover : atomic) : atomic

out.lock ? (lock ? mover : atomic) : cmpd

Type Inference for Atomicity

Our type checker provides fairly promising results, but it does require the programmer to fully annotate the code.

We've seen the amount of annotations required is fairly high and complex.

To address this shortcoming, we now develop a type inference algorithm for atomicity.

Type Inference for AtomicityAlgorithm Overview

Two stage run:

• Infer locks (if any) protect each field using Rcc/Sat reduction to propositional satisfiability.

• Infer the most precise atomicity for each method, using a constraint-based analysis.

Atomicity Extensions for Type Inference

We now introduce an atomicity variable α. An open atomicity s is either an (explicit) atomicity a or an atomicity variable α.

Type InferenceDemo

1. infer guarded_by

2. infer class parameters

3. insert atomicity vars

Implementation

We have extended the type checker with inference.

We've managed to avoid exponential explosion by reducing duplicate subterms.

Consider the sequential composition of two conditional atomicities:

(l ? a1 : a2) ; (l ? a3 : a4)

become

l ? (l ? a1;a3) : (l ? a1;a4) : (l ? (a2;a3) : (a2;a4))

Avoiding exponential explosion

Using the following simplification rules

l ? (l ? a1;a3) : (l ? a1;a4) : (l ? (a2;a3) : (a2;a4)) becomes (l ? a1 ; a3) : (l ? a2 ; a4)

Benchmarks

Limitations

A programmer must annotate correctly, otherwise the checker will not be very useful.

Example: The programmer wrongly assumed only synchronized methods should be atomic:

Limitations Cont'd.

Clearly deposit should be atomic as well but due to the lack of annotations the checker will not warn about this.

Conclusion

Atomicity can be expressed using a type system.

Atomicity is not the same as race conditions.

We can build an effective automatic checker for this type of system.

We can reduce a lot of manual labour by automatically inferring atomicity.

Questions?

types for atomicity authors: cormac flanagan, uc santa cruz stephen freund, marina lifshin, williams...

Documents

int balance

race conditions

race condition free

synchronized int

return balance

void deposit int

new balance

typebased race detection