1 / 23

Specifying Java Thread Semantics Using a Uniform Memory Model

Specifying Java Thread Semantics Using a Uniform Memory Model. Jason Yue Yang Ganesh Gopalakrishnan Gary Lindstrom School of Computing University of Utah. Multithreading in Java. Supported at language level Need a formal memory model (thread semantics) Current JMM

austin-barry
Download Presentation

Specifying Java Thread Semantics Using a Uniform Memory Model

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. Specifying Java Thread Semantics Using a Uniform Memory Model Jason Yue Yang Ganesh Gopalakrishnan Gary Lindstrom School of Computing University of Utah

  2. Multithreading in Java • Supported at language level • Need a formal memory model (thread semantics) • Current JMM • Java Language Specification, Chap 17 • It is broken

  3. Problems with the Current JMM • Too strong • Strict ordering constraints • Strict synchronization visibility requirements • Too weak • Reference escaping prematurely from constructor • Final field specification omitted • Volatile variable operations have no visibility requirement on normal variable operations

  4. Example: Double-Checked Locking Idiom is Broken class foo { private static Resource resource = null; public static Resource get() { if (resource == null) { synchronized (this) { if (resource == null) resource = new Resource(); } } return resource; } }

  5. Improvement Efforts • JSR-133: JMM and thread specification • JMM mailing list • http://www.cs.umd.edu/~pugh/java/memoryModel • Replacement proposals • Manson and Pugh’s Model (JMMMP) • Based on set notation • The CRF Model (JMMCRF) • Commit / Reconcile / Fence

  6. Motivations • Stronger capability of formal verification • More uniform notation • Greater flexibility • More comprehensive support for language level models • E.g., local variable behaviors in thread interactions

  7. UMM (Uniform Memory Model) • Abstract transition system • Memory model specified as guarded commands • Executable with an integrated model checker • Flexible configuration • Can specify various memory models • Uniform architecture • Parameterizes differences among memory models • Semantics primarily based on JMMMP

  8. UMM Conceptual Architecture Threadi Threadj LVi LIB – Local Instruction BufferLV– Local Variable Array GIB – Global Instruction BufferLK– Lock Array LIBi LIBj LVj GIB LK

  9. Instruction Definition • <t, pc,op, var, data, local, useLocal, lock, time> • t: issuing thread • pc: program counter • op: operation type • var: variable • data: data value • local: local variable • useLocal: tag for using local variable • lock: lock • time: global time stamp

  10. Critical Memory Model Properties • Program order • Instruction order determined by software • Visibility order • Final observable order perceived by threads • Mutual exclusion

  11. General Strategy in UMM • Enabling mechanism • Program order may be relaxed to enable certain interleaving • Controlled via bypassing table • Filtering mechanism • Legal execution trace constructed from GIB following proper ordering requirements • Enforced in readselection rules

  12. Transition TableExample:read and write operations

  13. Bypassing Policies • Controlled by table BYPASS • ready(i), iff  jLIBt(i) : pc(j) < pc(i)  (localDependent(i, j)  BYPASS[op(j)][op(i)] = No)

  14. Condition legalNormalRead • EnforcesSerialization • Read gets data from the most recent previous write • legalNormalRead(i), iff op(w) = WriteNormal var(w) = var(r)  (  w’GIB : op(w’) = WriteNormal var(w’) = var(r)  ordered(i, w’) ordered(w’, w) )

  15. The Ordering Requirement • Operations i1 and i2 are ordered, iff they are • ordered by program order, • synchronized by the same lock or volatile variable, or • transitively ordered by another intermediate operation • ordered(i1, i2), iff programOrdered(i1, i2)  synchronized(i1, i2)  (  i’GIB : ordered(i1, i’) ordered(i’, i2) )

  16. UMM Implementation in Mur • The JMM engine • Precisely defines the thread semantics • Primarily based on semantics of JMMMP • Implemented as Mur rules and functions • Test Suite • Carefully picked test cases • Captures the essence of interesting properties • Implemented with corresponding Mur initial states and invariants

  17. Analysis of the JMM • Ordering Property • Coherence • Write atomicity • Causality • Prescient write • Synchronization Property • Constructor Property

  18. Example: Prescient Write Behavior Initially, a = 0 Finally, can it result in r1 = 1 & r2 = 1? • Result: Yes • Hence, anti-dependence (Read after Write)is not guaranteed

  19. Benefits • Support for formal verification • Executable style – finds results immediately • Exhaustive enumeration – reveals corner cases • Rigorous specification – reduces ambiguities • Generic and uniform interface • Enables configuration and comparison • Simple architecture • Eliminates architecture-specific complexities

  20. Limitations • Not intended to be the actual implementation • State explosion problem • Limited to simple test cases

  21. Ongoing Efforts • Comprehensive coverage for many common memory models • Support for theorem proving technique

  22. For More Information … • UMM prototype • http://www.cs.utah.edu/~yyang/research • JMM mailing list archive • http://www.cs.umd.edu/~pugh/java/memoryModel/ • JSR-133: JMM and thread specification • http://jcp.org/jsr/detail/133.jsp • JSR-166: Concurrency utility • http://jcp.org/jsr/detail/166.jsp

  23. Thank you!

More Related