1. CSE 788.07, Autumn 2011 Michael Bond

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

3.  Introductions  Motivation: concurrency correctness  Course overview & survey  Background  Program analysis

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

8.  Atomicity  Ordering  Sequential consistency  Progress Programmers use synchronization to enforce these

9. More synchronizationLess synchronization More concurrencyLess concurrency

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

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

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

16. * Definition for this research area Check or guarantee

17. Static analysisDynamic analysis Analyze static codeAnalyze running program Find errors in any executionFind errors in some real execution Sound: no false negatives*Unsound: false negatives Imprecise: false positivesPrecise: often no false positives Doesn’t slow running programSlows executing program

18. Static analysisDynamic analysis Analyze static codeAnalyze running program Find errors in any executionFind errors in some real execution Sound: no false negatives*Unsound: false negatives Imprecise: false positivesPrecise: often no false positives Doesn’t slow running programSlows executing program False positive: reported “bug” isn’t really a bug (declare correct program incorrect) False negative: miss a bug (declare incorrect program correct)

19. Static analysisDynamic analysis Analyze static codeAnalyze running program Find errors in any executionFind errors in some real execution Sound: no false negatives*Unsound: false negatives Imprecise: false positivesPrecise: often no false positives Doesn’t slow running programSlows 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 Often dynamically sound: Reports all bugs in this execution

20. Static analysisDynamic analysis Analyze static codeAnalyze running program Find errors in any executionFind errors in some real execution Sound: no false negatives*Unsound: false negatives Imprecise: false positivesPrecise: often no false positives Doesn’t slow running programSlows executing program Conservative: 1.Concurrent execution 2.Approximating heap 3.Dynamic class loading & reflection Conservative: 1.Concurrent execution 2.Approximating heap 3.Dynamic class loading & reflection Most realistic executions are on deployed (production) systems!

21. 1. Name (& nickname if applicable) 2. Program (PhD/master’s) & year (1 st, 2 nd, etc.) 3. Why taking class? 4. Research interests & current research advisor (if any) 5. Background (grad & undergrad): PL, compilers, architecture, parallel programming, runtime systems, SE 6. Available times on Mondays and Wednesdays 7. 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?

22. CSE 788.07, Autumn 2011 Michael Bond

24. 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. 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.  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.  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.  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. 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. Java provides memory & type safety

31.  Buffer overflows, dangling pointers, array out-of- bounds, double frees, some memory leaks  How are these handled? With exceptions?

32. 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.  Data-race freedom & sequential consistency  Locking discipline  Atomicity

34.  Data-race freedom & sequential consistency  Locking discipline  Atomicity  Also: enforcing atomicity  Also: record & replay

35.  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.  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.  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. T1: data =...; flag = true; 38 T2: if (flag)... = data; Initially: int data = 0; boolean flag = false;

39. T1: data =...; flag = true; 39 T2: if (flag)... = data; Initially: int data = 0; boolean flag = false;

40. T1: data =...; flag = true; 40 T2: if (flag)... = data; Initially: int data = 0; boolean flag = false;

41. T1: flag = true; data =...; 41 T2: if (flag)... = data; Initially: int data = 0; boolean flag = false;

42. T1: flag = true; data =...; 42 T2: if (flag)... = data; Initially: int data = 0; boolean flag = false; Why a sequential consistency violation?

43. T1: data =...; flag = true; 43 T2: tmp = data; if (flag)... = tmp; Initially: int data = 0; boolean flag = false;

44. T1: data =...; synchronized (m) { flag = true; } 44 T2: boolean tmp; synchronized (m) { tmp = flag; } if (tmp)... = data; Initially: int data = 0; boolean flag = false;

45. 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-before relationship

46. T1: data =...; flag = true; 46 T2: if (flag)... = data; Initially: int data = 0; volatile boolean flag = false; Happens-before relationship

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

49. class Movie { Set comments; addComment(String s) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

50. class Movie { Set comments; addComment(String s) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

51. class Movie { Set comments; addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

52. addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); } addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

53. addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { HashSet temp = alloc HashSet; temp. (); comments = temp; } comments.add(s); } addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

54. addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { HashSet temp = alloc HashSet; temp. (); comments = temp; } comments.add(s); } addComment(String s) { if (comments == null) { synchronized (this) { if (comments == null) { comments = new HashSet (); } comments.add(s); }

55. 55 class Vector { synchronized boolean contains(Object o) {... } synchronized void add(Object o) {... } }

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