Dynamic Program Analysis and Runtime Systems for Reliable Concurrent Software: Introduction & Background

1. CSE 788.07, Autumn 2011 Michael Bond Dynamic Program Analysis and Runtime Systems forReliable Concurrent Software:Introduction & Background

2. Introductions • Name • Program & year • Where are you coming from? • Research interests • Or what’s something you find interesting? • Research advisor, if any

3. Outline • Introductions • Motivation: concurrency correctness • Course overview & survey • Background • Program analysis

4. Hardware becoming more parallel(more instead of faster cores)Software must become more parallel

5. Writing concurrent softwareis notoriously difficult

6. Writing concurrent softwareis notoriously difficultSo is reproducing, diagnosing, and fixing concurrency bugs

7. Shared memory programming • Imperative programs • Java, C#, C, C++, Python, Ruby • Threads • Shared mutable state • Lock-unlock, wait-notify, start-join

8. Concurrency correctness • Atomicity • Ordering • Sequential consistency • Progress Programmers use synchronization to enforce these

9. Less synchronization More synchronization More concurrency Less concurrency

10. Less synchronization More synchronization More concurrency Less concurrency Concurrency bugs: atomicity, order, & sequential consistency violations

11. Less synchronization More synchronization More concurrency Less concurrency Concurrency bugs: atomicity, order, & sequential consistency violations Concurrency bugs: deadlocks Poor performance: lock contention, serialization

12. Less synchronization More synchronization More concurrency Less concurrency Concurrency bugs: atomicity, order, & sequential consistency violations Concurrency bugs: deadlocks Concurrent & correct Poor performance: lock contention, serialization

13. Amdahl’s LawGustafson’s Law

14. Amdahl’s Law: speedup bounded by sequential computationGustafson’s Law: as problem size grows, sequential part won’t grow as much

15. Program analysis:

16. Program analysis:Ensure some correctness property* Check or guarantee * Definition for this research area

18. False positive: reported “bug” isn’t really a bug (declare correct program incorrect) False negative: miss a bug (declare incorrect program correct)

19. Often dynamically sound: Reports all bugs in this execution False positive: reported “bug” isn’t really a bug (declare correct program incorrect) False negative: miss a bug (declare incorrect program correct)

20. Conservative: Concurrent execution Approximating heap Dynamic class loading & reflection Most realistic executions are on deployed (production) systems!

21. Survey • Name (& nickname if applicable) • Program (PhD/master’s) & year (1st, 2nd, etc.) • Why taking class? • Research interests & current research advisor (if any) • Background (grad & undergrad): PL, compilers, architecture, parallel programming, runtime systems, SE • Available times on Mondays and Wednesdays • How likely you’ll stay in class (% or explain)? • Paper(s) you’d like to present (if any) • Feedback so far? • Concerns about forwarding critiques to all?

22. CSE 788.07, Autumn 2011 Michael Bond Dynamic Program Analysis and Runtime Systems forReliable Concurrent Software:Introduction & Background, Day 2

23. Questions on class, policies, or material from last time?

24. 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?

25. 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?

26. 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)

27. 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?

28. 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?

29. 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

30. Concurrency exceptions?! Java provides memory & type safety

31. 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?

32. 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?

33. Concurrency exceptions • Data-race freedom & sequential consistency • Locking discipline • Atomicity

34. Concurrency exceptions & enforcement • Data-race freedom & sequential consistency • Locking discipline • Atomicity • Also: enforcing atomicity • Also: record & replay

35. 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?

36. 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?

37. 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

38. Is there a data race? Initially: intdata = 0; booleanflag = false; T2: if (flag) ... = data; T1: data = ...; flag = true;

39. Is there a data race? Initially: intdata = 0; booleanflag = false; T2: if (flag) ... = data; T1: data = ...; flag = true;

40. Is that really so bad? Initially: intdata = 0; booleanflag = false; T2: if (flag) ... = data; T1: data = ...; flag = true;

41. Is that really so bad? Initially: intdata = 0; booleanflag = false; T2: if (flag) ... = data; T1: flag = true; data = ...;

42. Is that really so bad? Initially: intdata = 0; booleanflag = false; T2: if (flag) ... = data; Why a sequential consistency violation? T1: flag = true; data = ...;

43. Is that really so bad? Initially: intdata = 0; booleanflag = false; T2: • tmp = data; if (flag) ... = tmp; T1: data = ...; flag = true;

44. Is there a data race? Initially: intdata = 0; booleanflag = false; T2: • booleantmp; • synchronized (m) { • tmp = flag; • } if (tmp) ... = data; T1: data = ...; synchronized (m) { flag = true; }

45. Is there a data race? Initially: intdata = 0; booleanflag = false; T2: • booleantmp; • acquire(m); • tmp = flag; • release(m); if (tmp) ... = data; Happens-before relationship T1: data = ...; acquire(m); flag = true; release(m);

46. Is there a data race? Initially: intdata = 0; volatilebooleanflag = false; T2: if (flag) ... = data; Happens-before relationship T1: data = ...; flag = true;

47. 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?

48. Additional slides (if time)

49. Another example: double-checked locking class Movie { Set<String> comments; addComment(String s) { if (comments == null) { comments = new HashSet<String>(); } comments.add(s); } }

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