Coqa : C oncurrent O bjects with Q uantized A tomicity

1. Coqa: Concurrent Objects with Quantized Atomicity Yu David Liu, Xiaoqi Lu, Scott Smith Johns Hopkins University April 4, 2008 @ CC’08

2. 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.

3. 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.

4. Coqa Object Model A Minimalistic Model with Three Messaging Expressions. • * Threads in Coqa are called “tasks”.

5. htable Bob Cathy Alice Time L3 L1 L1 L2 L4 L4 L4 L3 L2 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(); } read lock write lock t1 transfer("Alice", "Bob", 300) t2 transfer(“Cathy”,”Alice”, 500) t1 t1 t1 t2 t2 t2

6. 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.

7. htable t2 Bob Dan Alice Time L5 L6 L6 public void openAccount(String n, int bal) { L5 Acct newAcct= new Acct(n, bal); L6 htable.put(n, newAcct); } t1 transfer("Alice", "Bob", 300); t2 openAccount(“Dan”, 1000); t1 t1 t1

8. htable t2 Bob t2 t1 t3 Dan Alice Time L1 L5 L6 Subtasking for More Concurrency 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); } } 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); } t3

9. 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.

10. … … … … Equivalent quantum2 quantum1 … … … … quantum2 quantum1 … … … … … quantum Time Quantized 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.

11. 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 C200100 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.

12. 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 C200100 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.

13. 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

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. Thank you!