1 / 21

Coqa : C oncurrent O bjects with Q uantized A tomicity

Coqa : C oncurrent O bjects with Q uantized A tomicity. 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.

tuan
Download Presentation

Coqa : C oncurrent O bjects with Q uantized A tomicity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related