Coqa: Concurrent Objects with Quantized Atomicity

Yu David Liu, Xiaoqi Lu, Scott Smith

Johns Hopkins University

April 4, 2008 @ CC’08

Why and What?• Demand: Multi-Core Programming

– Complex interleaving scenarios need language-level atomicity support.– Widespread use of multi-core CPUs needs simple and intuitive

programming abstractions.

• Supply: Coqa– A correctness-oriented language: all Coqa code ubiquitously preserves a

flavor of atomicity.• Fewer interleaving scenarios make less error-prone code for programmers.• Fewer interleaving scenarios allow for new program analysis techniques.

– Additional correctness guarantees:• no race conditions exist for field access. • default mutual exclusive object access for threads.

– Deeply embedding concurrency into a familiar Java-like object model.

Why and What?• Demand: Multi-Core Programming

– Complex interleaving scenarios need language-level atomicity support.– Widespread use of multi-core CPUs needs simple and intuitive

programming abstractions.

• Supply: Coqa– A correctness-oriented language: all Coqa code ubiquitously preserves a

flavor of atomicity.• Fewer interleaving scenarios make less error-prone code for programmers.• Fewer interleaving scenarios allow for new program analysis techniques.

– Additional correctness guarantees:• no race conditions exist for field access. • default mutual exclusive object access for threads.

– Deeply embedding concurrency into a familiar Java-like object model.

Coqa Object Model

A Minimalistic Model with Three Messaging Expressions.

expression usage

o.m(v) Intra-task synchronous messaging

o=>m(v) Subtasking

o->m(v) Task creation

* Threads in Coqa are called “tasks”.

class Bank{ void transfer (String from, String to, int bal){ L1 Acct afrom = (Acct)htable.get(from); L2 afrom.withdraw(bal); L3 Acct ato = (Acct)htable.get(to); L4 ato.deposit(bal); } private HashTable htable = new HashTable(); }

htable Alice Bob Cathy

t1 transfer("Alice", "Bob", 300)

t2 transfer(“Cathy”,”Alice”, 500)

t1 t1t1

t2

L1 L2 L1 L2 L3 L3 L4L4

t2

L4

t2

Time

read lock

write lock

Synchronous Messaging and Atomicity

• Philosophically, Coqa represents an inversion of the default mode from Java: each and every task (as it is now) is atomic.

• Stronger than Java’s “synchronized’’ declaration in that Coqa atomicity is deep.

• With the design as it is, a method might run too long so that long wait of object release is possible; programs are prone to deadlocks.

t1 transfer("Alice", "Bob", 300);

t2 openAccount(“Dan”, 1000);

htable Alice Bob Dant1 t1t1

t2

public void openAccount(String n, int bal) {

L5 Acct newAcct= new Acct(n, bal);

L6 htable.put(n, newAcct);

}

L5 L6 L6

Time

class Bank{ void transfer (String from, String to, int bal){ L1 Acct afrom = (Acct)htable => get(from); L2 afrom.withdraw(bal); L3 Acct ato = (Acct)htable => get(to); L4 ato.deposit(bal); } }

L1 L5 L6

htable Alice Bob Dant3

t2

t1

t2

t3

transfer("Alice", "Bob", 300);

openAccount(“Dan”, 1000);

void openAccount(String n, int bal) {L5 Acct newAcct = new Acct(n, bal); L6 htable.put(n.newAcct); }

Subtasking for More Concurrency

Time

Subtasking

• Subtasking captures the high-level intuition of a relatively independent “subtask” that can independently claim victory by freeing objects early.

• Subtasking is synchronous.• Subtasking to Coqa is open nesting to some STM

systems.• A Coqa subtask can access the objects locked by its

“parent” task. • Subtasking encourages more concurrency at the

expense of breaking whole-task atomicity.

• Does a loss of whole-task atomicity imply that no atomicity property can be preserved?

• A task is a sequence of atomic zones, quanta. Each quantum consists of a sequence of serializable execution steps.

quantumquantum2quantum1

Time

… ………

… … …… …

………quantum1 quantum2

…

Quantized Atomicity

Equivalent

Why Quantized Atomicity?• It significantly reduces the number of interleavings: an application is usually

composed of few tasks, each with a very limited number of quanta.– If two Java threads each have 100 steps of execution, there are C200

100 interleaving scenarios.

– If the two threads are modeled by Coqa tasks, each formed by 3 quanta, there are only C63 =

20 scenarios.• For next-generation program analysis tool designers: enumerating all

interleavings are now possible.• For programmers,

– Each quantum is still atomic, so it is easy to understand.– Across quanta, objects accessed by subtasks might not be atomically accessed, but mutual

exclusive access still holds for all other objects.

Why Quantized Atomicity?• It significantly reduces the number of interleavings: an application is usually

composed of few tasks, each with a very limited number of quanta.– If two Java threads each have 100 steps of execution, there are C200

100 interleaving scenarios.

– If the two threads are modeled by Coqa tasks, each formed by 3 quanta, there are only C63 =

20 scenarios.• For next-generation program analysis tool designers: enumerating all

interleavings are now possible.• For programmers,

– Each quantum is still atomic, so it is easy to understand.– Across quanta, objects accessed by subtasks might not be atomically accessed, but mutual

exclusive access still holds for all other objects.

Task Creation

class Bank{ void main(String args[]){

… bank -> transfer ("Alice", "Bob", 300); bank -> transfer ("Cathy", "Alice", 500); }}

• Tasking creation via asynchronous messaging• Non-blocking, return immediately

Theoretical Results• Theorem: Quantized atomicity holds for all Coqa programs.

– For any execution path, there exists an equivalent quantized path, i.e. with every quantum serialized.– Proof technique: moving interleaved execution steps to obtain an equivalent non-interleaved execution path. [Lipton 75]

• Corollary: Race conditions of fields never happens.• Corollary: If an object is accessed via synchronous messaging, then mutual exclusive access to that object is

guaranteed for that task, across quanta.

Implementation: CoqaJava

• A Java extension built using Polyglot. Java core features are included.

• Benchmark programs– Contention-intensive: “sliding blocks” puzzle solver.– Computation-intensive: JavaGrande RayTracer.

• Preliminary optimizations– Task object pool and immutable fields.– Manually annotated task-local objects.

• Preliminary Result: 15-60% slower than Java.

On-going Efforts

• Performance improvement– Inferring task-local objects.– JVM modifications.

• Toward deadlock freedom– Coqa, like other lock-based strategies, can lead to deadlocks.– Subtasking provides a partial solution to alleviate deadlocks.– New design: a “typed” version of Coqa with regions.

• Object types include information on which task (region) the object belongs to.

• A freed object can be obtained by other tasks by type casting.

• Java– Mutual exclusion is supported. No atomicity support. – Properties preserved only if programmers declare them. – Not building concurrency at the core leads to a somewhat complex memory model.

• Actors– Minimalistic model with atomicity guarantees.– Asynchronous messaging: difficult to program.– Atomicity holds for code blocks typically shorter than Coqa ones.

• Software Transactional Memory (STM) Systems– No deadlocks, but livelocks are possible.– No atomicity unless declared. Weak atomicity when transactional code runs with non-

transactional code.– I/Os (GUIs, networking) can not rollback. – Coqa could be implemented by replacing locking with rollbacks.

Existing Technologies

• Java– Mutual exclusion is supported. No atomicity support. – Properties preserved only if programmers declare them. – Not building concurrency at the core leads to a somewhat complex memory model.

• Actors– Minimalistic model with atomicity guarantees.– Asynchronous messaging: difficult to program.– Atomicity holds for code blocks typically shorter than Coqa ones.

• Software Transactional Memory (STM) Systems– No deadlocks, but livelocks are possible.– No atomicity unless declared. Weak atomicity when transactional code runs with non-

transactional code.– I/Os (GUIs, networking) can not rollback. – Coqa could be implemented by replacing locking with rollbacks.

Existing Technologies

• Java– Mutual exclusion is supported. No atomicity support. – Properties preserved only if programmers declare them. – Not building concurrency at the core leads to a somewhat complex memory model.

• Actors– Minimalistic model with atomicity guarantees.– Asynchronous messaging: difficult to program.– Atomicity holds for code blocks typically shorter than Coqa ones.

• Software Transactional Memory (STM) Systems– No deadlocks, but livelocks are possible.– No atomicity unless declared. Weak atomicity when transactional code runs with non-

transactional code.– I/Os (GUIs, networking) can not rollback. – Coqa could be implemented by replacing locking with rollbacks.

Existing Technologies

Conclusion

• A correctness-oriented model: – ubiquitous quantized atomicity: both good for programmer

comprehension and for designing new program analysis techniques.

– automatic mutual exclusion. – race condition freedom.

• A minimalistic object model very similar to Java.• End goal: A model toward simple and correct multi-core

programming.

Thank you!