cse 788.07, autumn 2011 michael bond. name program & year where are you coming from? ...
TRANSCRIPT
Dynamic Program Analysis and Runtime Systems forReliable Concurrent Software:Introduction & Background
CSE 788.07, Autumn 2011Michael Bond
Introductions
Name Program & year Where are you coming from? Research interests
Or what’s something you find interesting?
Research advisor, if any
Outline
Introductions Motivation: concurrency correctness Course overview & survey Background
Program analysis
Hardware becoming more parallel
(more instead of faster cores)
Software must become more parallel
Writing concurrent software
is notoriously difficult
Writing concurrent software
is notoriously difficult
So is reproducing, diagnosing, and fixing
concurrency bugs
Shared memory programming
Imperative programs Java, C#, C, C++, Python, Ruby
Threads Shared mutable state Lock-unlock, wait-notify, start-join
Concurrency correctness
Atomicity Ordering Sequential consistency
Progress
Programmers use synchronization to enforce these
More synchronizationLess synchronization
More concurrency Less concurrency
More synchronizationLess synchronization
Concurrency bugs: atomicity, order, &sequential consistency violations
More concurrency Less concurrency
More synchronizationLess synchronization
Concurrency bugs: atomicity, order, &sequential consistency violations
More concurrency
Concurrency bugs: deadlocks
Poor performance: lock contention, serialization
Less concurrency
More synchronizationLess synchronization
Concurrency bugs: atomicity, order, &sequential consistency violations
More concurrency
Concurrency bugs: deadlocks
Poor performance: lock contention, serialization
Concurrent & correct
Less concurrency
Amdahl’s Law
Gustafson’s Law
Amdahl’s Law: speedup bounded by sequential
computation
Gustafson’s Law: as problem size grows, sequential part
won’t grow as much
Program analysis:
Program analysis:Ensure some correctness
property*
* Definition for this research area
Check or guarantee
Static analysis Dynamic analysis
Analyze static code Analyze running program
Find errors in any execution Find errors in some real execution
Sound: no false negatives* Unsound: false negatives
Imprecise: false positives Precise: often no false positives
Doesn’t slow running program Slows executing program
Static analysis Dynamic analysis
Analyze static code Analyze running program
Find errors in any execution Find errors in some real execution
Sound: no false negatives* Unsound: false negatives
Imprecise: false positives Precise: often no false positives
Doesn’t slow running program Slows executing program
False positive: reported “bug” isn’t really a bug(declare correct program incorrect)
False negative: miss a bug(declare incorrect program correct)
Static analysis Dynamic analysis
Analyze static code Analyze running program
Find errors in any execution Find errors in some real execution
Sound: no false negatives* Unsound: false negatives
Imprecise: false positives Precise: often no false positives
Doesn’t slow running program Slows executing program
False positive: reported “bug” isn’t really a bug(declare correct program incorrect)
False negative: miss a bug(declare incorrect program correct)
Often dynamically sound:Reports all bugs in this execution
Static analysis Dynamic analysis
Analyze static code Analyze running program
Find errors in any execution Find errors in some real execution
Sound: no false negatives* Unsound: false negatives
Imprecise: false positives Precise: often no false positives
Doesn’t slow running program Slows executing programConservative:1. Concurrent
execution2. Approximating heap3. Dynamic class
loading & reflection
Most realistic executions are on
deployed (production) systems!
Survey
1. Name (& nickname if applicable)2. Program (PhD/master’s) & year (1st, 2nd, etc.)3. Why taking class?4. Research interests & current research advisor (if any)5. Background (grad & undergrad): PL, compilers,
architecture, parallel programming, runtime systems, SE6. Available times on Mondays and Wednesdays7. How likely you’ll stay in class (% or explain)?8. Paper(s) you’d like to present (if any)9. Feedback so far?10.Concerns about forwarding critiques to all?
Dynamic Program Analysis and Runtime Systems forReliable Concurrent Software:Introduction & Background, Day 2
CSE 788.07, Autumn 2011Michael Bond
Questions on class, policies, or material from
last time?
Responding to feedback & clarifying policies
Critiques Critiques sent to everyone, but anonymous Don’t write critique if leading discussion
Discussion leaders Covering in interactive way: paper’s main points,
plus critical analysis & opportunities Send scheduling e-mail: 4 weekdays before class▪ Full availability & current status/outline
Send outline: day before our meeting Volunteer for next time?
Responding to feedback & clarifying policies
Meeting I/we need to talk louder Coffee
Logistics 16 enrolled, ~16 papers replace
presentations? Discussion leader for next time? Dropping/auditing? – contact me Got my e-mail?
For next time
Read papers Meet with group tomorrow Send critique by 5 pm Read critiques before class
Before class: send paper(s) you’d like to present
Also start looking at papers for project topic selection (preliminary proposal due Thursday next week)
For next time
Read papers Meet with group tomorrow Send critique by 5 pm Read critiques before class
Before class: send paper(s) you’d like to present
Also start looking at papers for project topic selection (preliminary proposal due Thursday next week)
Questions?
Forming groups
1–2 or 2–3: SJ 11–12: MFS Another time (8:30–10:30, 11:30–
1:30): DH
Will you have time to write critiques after meeting?
Motivation for course content
Critiques & discussions – critically evaluate research & develop new ideas; understand ideas & concepts deeply
Project – practice research process; make research contribution
Motivation for material – more in 885
Concurrency exceptions?!
Java provides memory & type safety
Concurrency exceptions?!
Java provides memory & type safety Buffer overflows, dangling pointers,
array out-of-bounds, double frees, some memory leaks
How are these handled? With exceptions?
Concurrency exceptions?!
Java provides memory & type safety Buffer overflows, dangling pointers,
array out-of-bounds, double frees, some memory leaks
How are these handled? With exceptions?
Should languages, runtime, & hardware systems provide concurrency correctness?
Concurrency exceptions
Data-race freedom & sequential consistency
Locking discipline Atomicity
Concurrency exceptions & enforcement
Data-race freedom & sequential consistency
Locking discipline Atomicity
Also: enforcing atomicity Also: record & replay
Concurrency exceptions & enforcement
Data-race freedom & sequential consistency
Locking discipline Atomicity
Also: enforcing atomicity Also: record & replay
Advantages of exceptions vs. enforcement?
Easier to provide exceptions vs. enforcement?
Concurrency exceptions & enforcement
Data-race freedom & sequential consistency
Locking discipline Atomicity
Also: enforcing atomicity Also: record & replay
Advantages of exceptions vs. enforcement?Easier to provide exceptions vs.
enforcement?
Questions or other issues in paper?
Data races & sequential consistency
Two accesses to same variable At least one is a write
Not well-synchronized(not ordered by happens-before relationship)
Or: accesses can happen simultaneously
Is there a data race?
T1:
data = ...;flag = true;
38
T2:
if (flag)
... = data;
Initially:
int data = 0;
boolean flag = false;
Is there a data race?
T1:
data = ...;flag = true;
39
T2:
if (flag)
... = data;
Initially:
int data = 0;
boolean flag = false;
Is that really so bad?
T1:
data = ...;flag = true;
40
T2:
if (flag)
... = data;
Initially:
int data = 0;
boolean flag = false;
Is that really so bad?
T1:
flag = true;
data = ...;
41
T2:
if (flag)
... = data;
Initially:
int data = 0;
boolean flag = false;
Is that really so bad?
T1:
flag = true;
data = ...;
42
T2:
if (flag)
... = data;
Initially:
int data = 0;
boolean flag = false;
Why a sequential consistency violation?
Is that really so bad?
T1:
data = ...;flag = true;
43
T2:
tmp = data;
if (flag)
... = tmp;
Initially:
int data = 0;
boolean flag = false;
Is there a data race?
T1:
data = ...;synchronized (m) { flag = true;}
44
T2:
boolean tmp;
synchronized (m) {
tmp = flag;
}
if (tmp)
... = data;
Initially:
int data = 0;
boolean flag = false;
Is there a data race?
T1:
data = ...;acquire(m); flag = true;release(m);
45
T2:
boolean tmp;
acquire(m);
tmp = flag;
release(m);
if (tmp)
... = data;
Initially:
int data = 0;
boolean flag = false;
Happens-beforerelationship
Is there a data race?
T1:
data = ...;flag = true;
46
T2:
if (flag)
... = data;
Initially:
int data = 0;
volatile boolean flag = false;
Happens-beforerelationship
Concurrency exceptions & enforcement
Data-race freedom & sequential consistency
Locking discipline Atomicity
Also: enforcing atomicity Also: record & replay
Advantages of exceptions vs. enforcement?
Easier to provide exceptions vs. enforcement?
Additional slides (if time)
Another example: double-checked locking
class Movie { Set<String> comments;
addComment(String s) { if (comments == null) { comments = new HashSet<String>(); } comments.add(s); }}
Another example: double-checked locking
class Movie { Set<String> comments;
addComment(String s) { synchronized (this) { if (comments == null) { comments = new HashSet<String>(); } } comments.add(s); }}
Another example: double-checked lockingclass Movie { Set<String> comments;
addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet<String>(); } } } comments.add(s); }}
Another example: double-checked locking
addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new
HashSet<String>(); } } } comments.add(s);}
addComment(String s) {
if (comments == null) {
synchronized (this) {
if (comments == null) {
comments =
new HashSet<String>();
}
}
}
comments.add(s);
}
Another example: double-checked locking
addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { HashSet temp = alloc HashSet; temp.<init>(); comments = temp; } } } comments.add(s);}
addComment(String s) {
if (comments == null) {
synchronized (this) {
if (comments == null) {
comments =
new HashSet<String>();
}
}
}
comments.add(s);
}
Another example: double-checked locking
addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { HashSet temp = alloc HashSet; temp.<init>(); comments = temp; } } } comments.add(s);}
addComment(String s) {
if (comments == null) {
synchronized (this) {
if (comments == null) {
comments =
new HashSet<String>();
}
}
}
comments.add(s);
}
Atomicity violation without data races
55
class Vector { synchronized boolean contains(Object o) { ... } synchronized void add(Object o) { ... }}
Atomicity violation without data races
56
class Vector { synchronized boolean contains(Object o) { ... } synchronized void add(Object o) { ... }}
class Set { Vector vector; void add(Object o) { if (!vector.contains(o)) { vector.add(o); } }}