1. References
[1] LEAP:The Lightweight Deterministic Multi-processor Replay of Concurrent Java Programs
[2] CLAP:Recording Local Executions to Reproduce Concurrency Failures
[3] Persuasive Prediction of Concurrency Access Anomlies
[4] Maximal Sound Predictive Race Detection with Control Flow Abstraction
[5] Maximal Casual Models for Sequentially Consistent Systems

2. 1 Introduction
Concurrent programs are plagued by a class of bugs called Heisenbugs, such as data races, order violations, deadlocks atomicity violations, and atomic-set serializability violations that are easy to hatch but difficult to detect and to fix.

3. 1 Introduction
Concurrent programs are plagued by a class of bugs called Heisenbugs, such as data races, order violations, deadlocks atomicity violations, and atomic-set serializability violations that are easy to hatch but difficult to detect and to fix.
Concurrency bugs are notoriously difficult to test ,because of the non-determinism property of concurrent programs.

4. 1 Introduction
We have two techniques to deal with this problem.

5. 1 Introduction We have two techniques to deal with this problem.
One is the record and replay technique, it aims at fully reenacting the problematic execution of concurrent programs, thus giving the programmers both the context and the history information to dramatically expedite the process of bug fix.

6. 1 Introduction We have two techniques to deal with this problem.
One is the record and replay technique, it aims at fully reenacting the problematic execution of concurrent programs, thus giving the programmers both the context and the history information to dramatically expedite the process of bug fix.
A crucial design factor of record and replay solutions is amount of data to be recorded and degree of faithfulness in replay

7. 2 Record and Replay
Dejavu is a global clock
based approach.

8. 2 Record and Replay Dejavu is a global clock based approach.
Record a global order
of critial events.
Enforce the same global
order in replay phase.

9. 2 Record and Replay Dejavu is a global clock based approach.
Record a global order
of critial events.
Enforce the same global
order in replay phase.
<t1,t2,t1,t2,t2,t1,t1>

10. 2 Record and Replay
LEAP is a local-order based deterministic replay.

11. 2 Record and Replay LEAP is a local-order based deterministic replay.
Observation: it is sufficient to record partial thread access information local to the individual shared variables.

12. 2 Record and Replay LEAP is a local-order based deterministic replay.
Observation: it is sufficient to record partial thread access information local to the individual shared variables.
Record:
x:<t1,t2,t1>
y:<t2,t1,t2>

13. 2 Record and Replay
Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations

14. 2 Record and Replay
Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations
LEAP record x:<t1,t2,t1>,y:<t2,t1,t2>,record 6 operations, and recording on different memory locations can be parallelized.

15. 2 Record and Replay
Dejavu record <t1,t2,t1,t2,t2,t1,t1>, record 7 operations
LEAP record x:<t1,t2,t1>,y:<t2,t1,t2>,record 6 operations, and recording on different memory locations can be parallelized.
So LEAP is more efficient than Dejavu.

16. 2 Record and Replay
CLAP is a record and replay techniques based on SMT slover.
Main idea: do not record order but compute it.

17. 2 Record and Replay
CLAP is a record and replay techniques based on SMT slover.
Main idea: do not record order but compute it.
Record:log thread local execution paths at runtime.
Compute schedule through sloving constraints.

18. 2 Record and Replay
CLAP is a record and replay techniques based on SMT slover.
Main idea: do not record order but compute it.
Record:log thread local execution paths at runtime.
Compute schedule through sloving constraints.

19. 2 Record and Replay SMT slovers: Popular SMT slovers
- Z3,Yices,STP,MathSAT,CVC4,OpenSMT...

20. 2 Record and Replay SMT slovers: Popular SMT slovers
- Z3,Yices,STP,MathSAT,CVC4,OpenSMT...
x1<x2 & x2<x3 & x3<x1 ??

21. 2 Record and Replay SMT slovers: Popular SMT slovers
- Z3,Yices,STP,MathSAT,CVC4,OpenSMT...
x1<x2 & x2<x3 & x3<x1 ?? no solution!!

22. 2 Record and Replay SMT slovers: Popular SMT slovers
- Z3,Yices,STP,MathSAT,CVC4,OpenSMT...
x1<x2 & x2<x3 & x3<x1 ?? no solution!!
x1<x2 & x3<x4 & (x2<x3 | x1<x4) ??

23. 2 Record and Replay SMT slovers: Popular SMT slovers
- Z3,Yices,STP,MathSAT,CVC4,OpenSMT...
x1<x2 & x2<x3 & x3<x1 ?? no solution!!
x1<x2 & x3<x4 & (x2<x3 | x1<x4) ??
- [x1,x2,x3,x4]=[0,1,2,3]

24. 2 Record and Replay
Record:
- T1;[1,2,3,4] T2:[5,6,7]

25. 2 Record and Replay Record: - T1;[1,2,3,4] T2:[5,6,7]
O: order variable for each
shared data access
S: symbolic value for each
shared data read

26. 2 Record and Replay Constraints: Path Constraints:
- x3=Sx3,y6=Sy6,x3<0,y6==1

27. 2 Record and Replay Constraints: Path Constraints:
- x3=Sx3,y6=Sy6,x3<0,y6==1
Order Constraints:
- O1<O2<O3 O5<O6<O7

28. 2 Record and Replay Constraints: Path Constraints:
- x3=Sx3,y6=Sy6,x3<0,y6==1
Order Constraints:
- O1<O2<O3 O5<O6<O7
Read-Write Constrints:
- Sx3= x1 & (O7<O1 | O7>O3)| x7 & (O1<O7<O3)
- Sy6= y5 & (O2<O5 | O2>O6)| y2 & (O5<O2<O6)

29. 2 Record and Replay Path Constraints: - x3=Sx3,y6=Sy6,x3<0,y6==1
Order Constraints:
- O1<O2<O3 O5<O6<O7
Read-Write Constrints:
- Sx3= x1 & (O7<O1 | O7>O3)| x7 & (O1<O7<O3)
- Sy6= y5 & (O2<O5 | O2>O6)| y2 & (O5<O2<O6)
Slover:O1=2 O2=3 O3=6
O5=1 O6=4 O7=5

30. 2 Record and Replay Original Schedule:
<1,5,2,6,7,3,4> -> ERROR
Slover:
<5,1,2,6,7,3,4> -> ERROR

31. 3 Execution Model
The Other technique is predictive trace analysis(PTA).

32. 3 Execution Model
The Other technique is predictive trace analysis(PTA).
The PTA is a detection technique of concurrency bugs.

33. 3 Execution Model The common pattern for all these methods is
(1) The program is instrumented to trace the execution of programs

34. 3 Execution Model The common pattern for all these methods is
(1) The program is instrumented to trace the execution of programs
(2) One execution trace is recorded

35. 3 Execution Model The common pattern for all these methods is
(1) The program is instrumented to trace the execution of programs
(2) One execution trace is recorded
(3) An abstraction of that trace, i.e., a model, is derived

36. 3 Execution Model
(4) The obtained model is used to predict (problematic) event patterns occurring in other possible executions abstracted by it.

37. 3 Execution Model
Many PTA techniques are based on an execution model of concurrent programs.

38. 3 Execution Model
Many PTA techniques are based on an execution model of concurrent programs.
We wish execution model contains feasible traces as many as possible

39. 3 Execution Model
Many PTA techniques are based on an execution model of concurrent programs.
We wish execution model contains feasible traces as many as possible
Two properties of a good Execution Model
- Soundness, Maximality

40. 3 Execution Model Some this kind models:
The conventional happens-before causality: if two conflicting accesses to an object are not causally ordered, then a data-race is reported.

41. 3 Execution Model The model used by Pecan:
a hybrid constraint model that combines the lockset condition and the happens-before relation.

42. 3 Execution Model The model used by Pecan:
a hybrid constraint model that combines the lockset condition and the happens-before relation.
The Partial Order Relation (POR) ei →ej holds for Program order, Fork-join order, Wait-notify order

43. 3 Execution Model The model used by Pecan:
a hybrid constraint model that combines the lockset condition and the happens-before relation.
The Partial Order Relation (POR) ei →ej holds for Program order, Fork-join order, Wait-notify order
The Temporal Order Relation(TOR) ei-->ej

44. 3 Execution Model
Based on this model, Pecan get a Partial and Temporal Order Graph(PTG), and then search patterns in this Graph to detect concurrent bugs.

45. 3 Execution Model
Example:

46. 3 Execution Model
Example:
We get a trace <1,5,2,3,6,7>

47. 3 Execution Model e1: Write(1,1,x) e5: Write(2,2,y)
e2: Write(3,1,y) e6: Read(5,2,y)
e3: Read(4,1,x) e7: Write(6,2,x)

48. 3 Execution Model e1: Write(1,1,x) e5: Write(2,2,y)
e2: Write(3,1,y) e6: Read(5,2,y)
e3: Read(4,1,x) e7: Write(6,2,x)
POR: e1->e2->e e5->e6->e7
TOR: e1-->e3-->e7 (for x) e5-->e2-->e6 (for y)

49. 3 Execution Model
PTG:

50. 3 Execution Model
PTG:
We search patterns in this PTG and get for data race: (3,7) (5,2) (2,6) (1,7)

51. 3 Execution Model
But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race.

52. 3 Execution Model
But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race.
But Pecan can prune this false warning during re-execution phase

53. 3 Execution Model
But (1,7) is not a real data race. Because the execution of e7 is dependent on e6. If e7 occurs before e1, e6 must read the same value of y that the value of original trace. That is e2->e6, So(1,7) is not a data race.
But Pecan can prune this false warning during re-execution phase
So the hybrid constraint model is not sound because of it is a conservative approxmation. So Pecan may report false positives during the pattern search.

54. 3 Execution Model
A race between lines
(3,10).

55. 3 Execution Model A race between lines (3,10). An execution trace
<1,2,3,4,5,6,7,8,9,10,11,
12,13,14,15,16,17>

56. 3 Execution Model CP relax the HB edges between critical sections
that have no conflicting
accesses.

57. 3 Execution Model CP relax the HB edges between critical sections
that have no conflicting
accesses.
For the two lock regions
all accesses to y.CP cannot
detect this race

58. 3 Execution Model
PECAN is able to detect
this race.

59. 3 Execution Model PECAN is able to detect this race.
But if we switch lines 1
and 2, (3,10) is no longer a
race PECAN will still report it.

60. 3 Execution Model We get a trace <1,2,3,4>
(1,4) is a race in , but
not in .

61. 3 Execution Model We get a trace <1,2,3,4>
(1,4) is a race in , but
not in .
A sound technique conservatively creates a HB edge from line 2 to line 3 and misses the race in case .

62. 3 Execution Model With the control flow information, line 4 is not
control-dependent on line
3 in case .

63. 3 Execution Model With the control flow information, line 4 is not
control-dependent on line
3 in case .
we can safely drop the HB edge from line 2 to line 3, which enables detecting the race (1,4).

64. 3 Execution Model So,we can detect the race (3,10) by dropping the
HB edge from line 4 to line 8

65. 3 Execution Model
branch(t): jump to a new operation. We conservatively assume that the choice of branch(t) depends on all the previous read(t, x, v) operations executed by the same thread.

66. 3 Execution Model

67. 3 Execution Model

68. 3 Execution Model
Consistency of trace t means precisely the following:
Read Consisitency, Lock Mutual Exclusion, Must Happen-Before

69. 3 Execution Model
Consistency of trace t means precisely the following:
Read Consisitency, Lock Mutual Exclusion, Must Happen-Before
An consistent interleaving of t is a trace t' such that t|thread=t'|thead for each thread.

70. 3 Execution Model The Common Execution Model
for a trace t', iff t|thread=t'|thead for all thread, and t' satisfies the consistency property, t' feasible(P).

71. 3 Execution Model Consistent Interleavings of the
original trace such as,
<1,6,2,3,4,5,7,8,9...>
<1,2,6,3,4,5,7,8,9...>
are all belong to feasible(P)

72. 3 Execution Model Consistent Interleavings of the
original trace such as,
<1,6,2,3,4,5,7,8,9...>
<1,2,6,3,4,5,7,8,9...>
are all belong to feasible(P)
<1,6,7,8,9,2,3,4,5...>is not in
feasible(P)
because t|thread≠t'|thead

73. 3 Execution Model The Weaker Execution Model
Formally, if t1e1, t2 feasible(P) and
t1|thread(e1)= t2|thread(e1) then
(1) if t2e1 is consistent then t2e1 feasible(P)
(2) if op(e1) =read and there exists some event e2 with e2[data(e1)/data] = e1,and t2e2 consistent, then
t2e2 feasible(P).

74. 3 Execution Model The Weaker Execution Model
Formally, if t1e1, t2 feasible(P) and
t1|thread(e1)= t2|thread(e1) then
(1) if t2e1 is consistent then t2e1 feasible(P)
(2) if op(e1) =read and there exists some event e2 with e2[data(e1)/data] = e1,and t2e2 consistent, then
t2e2 feasible(P).
So <1,6,7,8',....> is in feasible(P), but <1,6,7,8',9...>is not.
8' is read(t2,y,0)

75. 3 Execution Model

76. 3 Execution Model Proof: t1:<1,2,3,4,5,6,7>
e1:8 t2:<1,6,7>, all feasible(P)
thread(e1)=th
t1|th= t2|th=<6,7>
but <1,6,7,8> is not consistent
<1,6,7,8> feasible(P)
8'=8[data(8)/0] and
<1,6,7,8'>is consistent
<1,6,7,8'> feasible(P)

77. 3 Execution Model
But <1,6,7,8',9> is not in feasible<P>

78. 3 Execution Model But <1,6,7,8',9> is not in feasible<P>
Because <1,6,7,8>|thread(9)≠<1,6,7,8'>|thread(9),9 is not a read event and <1,6,7,8',9>is not consistent because it can not satisfy Read Consistency.

79. 3 Execution Model The RVPredict Execution Model
Suppose that t1e1, t2 feasible(P) , that thread(e1) = th and that t1|th t2|th called data-abstract equivalence, iff they are equal except for the data values in read and write events.

80. 3 Execution Model The RVPredict Execution Model
Suppose that t1e1, t2 feasible(P) , that thread(e1) = th and that t1|th t2|th called data-abstract equivalence, iff they are equal except for the data values in read and write events.
Branch. If op(e1) = branch and t1|th,read = t2|th,read then t2e1 feasible(P).

81. 3 Execution Model
Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent,
then t2e2 feasible(p)

82. 3 Execution Model
Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent,
then t2e2 feasible(p)
Write. If op(e1) = write then there is a v such that t2e1[v/data] feasible(P), moreover,if t1|th,read =t2|th,read then v = data(e1).

83. 3 Execution Model
Read. If op(e1) = read and e2 is a (read) event such that e2[data(e1)/data]=e1 and t2e2 is consistent,
then t2e2 feasible(p)
Write. If op(e1) = write then there is a v such that t2e1[v/data] feasible(P), moreover,if t1|th,read =t2|th,read then v = data(e1).
Other. If op(e1) {branch,read,write} and t2e1 is consistent, then t2e1 feasible(P).

84. 3 Execution Model
Then <1,6,7,8',9...> is
in feasible(P)

85. 3 Execution Model Then <1,6,7,8',9...> is in feasible(P)
Proof:thread(9)=th
<1,6,7,8>|th <1,6,7,8'>|th
and op(9)=release;
and <1,6,7,8',9> is consistent,
so <1,6,7,8',9> feasible(P)

86. 3 Execution Model
The Sound and Maximal model contains branch events, so there are more feasible trace in it. Any PTAs which base on this execution model have a greater detection capability than other PTAs which base on other execution models.

87. 3 Execution Model
Because of some conservative assumption such as branch and write events depend upon all the reads by the same thread.
We think this limitation is too strong, as I think, branch and write events just can depend upon some read events by the same thread, but not all read events.
This strategy may give execution model a larger coverage than other execution model.