CSE 788.07, Autumn 2011 Michael Bond. Name Program & year Where are you coming from? ...

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); } }}