1 / 56

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

CSE 788.07, Autumn 2011 Michael Bond. Dynamic Program Analysis and Runtime Systems for Reliable Concurrent Software: Introduction & Background. Introductions. Name Program & year Where are you coming from? Research interests Or what’s something you find interesting?

clem
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

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

  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) Questions?

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

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

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

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

  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? Should languages, runtime, & hardware systems provide concurrency correctness?

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

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

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

  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? Questions or other issues in paper?

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

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

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

  39. Is that really so bad? 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: flag = true; data = ...;

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

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

  43. 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; }

  44. 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);

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

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

  47. Additional slides (if time)

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

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

More Related