Download ppt - University of Utah

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
• Java Language Specification, Chap 17
• It is broken
2
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
3
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;
}
}
4
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
5
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
6
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
7
UMM Conceptual Architecture
Threadi
LVi
Threadj
LIBi
LIBj
LVj
GIB
LK
LIB – Local Instruction Buffer
GIB – Global Instruction Buffer
LV – Local Variable Array
LK – Lock Array
8
Instruction Definition
 <t, pc,op, var, data, local, useLocal, lock, time>
•
•
•
•
•
•
•
•
•
t:
pc:
op:
var:
data:
local:
useLocal:
lock:
time:
issuing thread
program counter
operation type
variable
data value
local variable
tag for using local variable
lock
global time stamp
9
Critical Memory Model
Properties
Program order
• Instruction order determined by software
Visibility order
• Final observable order perceived by threads
Mutual exclusion
10
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
11
Transition Table Example:
read and write operations
Event
Condition
Action
readNormal
 iLIBt(i) :
ready(i)  op(i) = ReadNormal 
( wGIB: legalNormalWrite(i, w))
LVt(i)[local(i)] := data(w);
LIBt(i) := delete(LIBt(i), i);
writeNormal  iLIBt(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);
12
Bypassing Policies
 Controlled by table BYPASS
 ready(i), iff
 jLIB
t(i) :
pc(j) < pc(i) 
(localDependent(i, j)  BYPASS[op(j)][op(i)] = No)
13
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) )
14
The Ordering Requirement
 Operations i1 and i2 are ordered, iff they are
1) ordered by program order,
2) synchronized by the same lock or volatile variable, or
3) transitively ordered by another intermediate operation
 ordered(i1, i2), iff
programOrdered(i1, i2) 
synchronized(i1, i2) 
(  i’GIB : ordered(i1, i’)  ordered(i’, i2) )
15
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
16
Analysis of the JMM
Ordering Property
•
•
•
•
Coherence
Write atomicity
Causality
Prescient write
Synchronization Property
Constructor Property
17
Example:
Prescient Write Behavior
Initially, a = 0
Thread 1
Thread 2
r1 = a;
a = 1;
r2 = a;
a = r2;
Finally, can it result in r1 = 1 & r2 = 1?
Result: Yes
 Hence, anti-dependence (Read after
Write) is not guaranteed
18
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
19
Limitations
Not intended to be the actual implementation
State explosion problem
• Limited to simple test cases
20
Ongoing Efforts
Comprehensive coverage for many
common memory models
Support for theorem proving technique
21
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
22
Thank you!
23