Specifying Java Thread Semantics Using a Uniform Memory Model Jason Yue Yang Ganesh Gopalakrishnan...
-
date post
21-Dec-2015 -
Category
Documents
-
view
215 -
download
0
Transcript of Specifying Java Thread Semantics Using a Uniform Memory Model Jason Yue Yang Ganesh Gopalakrishnan...
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 levelNeed 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 specificationJMM 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 verificationMore uniform notationGreater flexibilityMore 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
LIB – Local Instruction Buffer LV – Local Variable Array
GIB – Global Instruction Buffer LK – Lock Array
LIBjLIBi
ThreadjThreadi
LVi 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 read selection rules
12
Transition Table Example:read and write operations
Event Condition Action
readNormal iLIBt(i) :
ready(i) op(i) = ReadNormal
( wGIB: legalNormalWrite(i, w))
LVt(i)[local(i)] := data(w);
LIBt(i) := delete(LIBt(i), i);
writeNormal iLIBt(i) :
ready(i) op(i) = WriteNormal
if (useLocal(i))
i.data := LVt(i)[local(i)];
end;
GIB := append(GIB, i);
LIBt(i) := delete(LIBt(i), i);
13
Bypassing Policies
Controlled by table BYPASS
ready(i), iff jLIBt(i) :
pc(j) < pc(i) (localDependent(i, j) BYPASS[op(j)][op(i)] = No)
14
Condition legalNormalRead
Enforces Serialization
• 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 are1) ordered by program order, 2) synchronized by the same lock or volatile variable, or3) 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 JMMOrdering Property
• Coherence• Write atomicity• Causality• Prescient write
Synchronization PropertyConstructor Property
18
Example: Prescient Write Behavior
Result: Yes Hence, anti-dependence (Read after
Write) is not guaranteed
Thread 1 Thread 2
r1 = a;
a = 1;
r2 = a;
a = r2;
Initially, a = 0
Finally, can it result in r1 = 1 & r2 = 1?
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 implementationState 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!