1 / 25

A taxonomy of race conditions

A taxonomy of race conditions. H.P.Helmbold , C.E.McDowell Eu-teum Choi Dependable System Lab. Contents. Introduction Events and Races Ordering properties of Races Other attributes of races Control vs Data Severity Feasibility Conclusion. Introduction. Non-deterministic Result

kiril
Télécharger la présentation

A taxonomy of race conditions

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. A taxonomy of race conditions H.P.Helmbold, C.E.McDowell Eu-teum Choi Dependable System Lab.

  2. Eu-teum Choi, DS Lab. Contents • Introduction • Events and Races • Ordering properties of Races • Other attributes of races • Control vs Data • Severity • Feasibility • Conclusion

  3. Eu-teum Choi, DS Lab. Introduction • Non-deterministic Result • The Intended deterministic.  synchronization error. • The Intended non-deterministic.  additional unwanted non-determinism. • Non-deterministic will be result in both cases. • In both cases it may be desirable to identify the sources of non-determinism when debugging a program. • “Race” • Two program event if they conflict. • Their execution order depends on how the threads are scheduled.

  4. Eu-teum Choi, DS Lab. Introduction • Netzer and Miller’s formal model • Two orthogonal attributes of races • One axis : general and data • Data race : A pair of conflicting accesses that can overlap • General race : A pair of conflicting accesses where the access order is not guaranteed. • Other axis : feasible, apparent and actual • Actual race : One that actually occurred in a particular execution and only applies to Data Race • Feasible race : A Race that did not occur but dose occur in another execution • Apparent race : One that appears possible based on the limited information in a trace, but cannot occur

  5. Eu-teum Choi, DS Lab. Introduction “1” is printed “0” is printed “0” is printed Race1 and race 2 is general races

  6. Eu-teum Choi, DS Lab. Events and Races • Definition 1 • An event is a contiguous sequence of one or more atomic operations executed by a single thread. Single thread begin x:=0; e1 if(y) then x:=1; en end e1 en

  7. Eu-teum Choi, DS Lab. Events and Races • Definition 2 • Simple statement : a statement of a programming language that does not contain any embedded statement Ex) x = 1; y = 0; • Compound statement :any group of syntactically contiguous simple statements. Ex) x = y+1; y= (x+3)/z; if(y) then x:=1;

  8. Eu-teum Choi, DS Lab. Events and Races • Definition 3 • Two event in different executions of the same program are equal if • They occur in the same thread, • Their constituent atomic operations are derived from the same simple source program statement, and • Both events are the nth occurrence of their constituent atomic operation sequences by the thread. Thread 1 Thread 1 e1 e1 Execution e2 e2 Execution 1 Execution N

  9. Eu-teum Choi, DS Lab. Events and Races • Definition 4 • Let events e1 and e2 be two events occurring in an execution of a program. If e1completes before e2begins then we say e1 occurred before e2, written e1e2. If e1begins before e2ends and e2begins before e1ends then the two events overlap. If either e1and e2overlap or e1e2, then we write e1  e2. e1 e1 e1  e2 or e2 e2 e1 occurred before e2 overlap

  10. Eu-teum Choi, DS Lab. Events and Races • Definition 5 • Fix an input to the program. Event e1is ordered before event e2if in every execution of the program on the input in which either event occurs, e1 e2. e1 e2 Every execution e2 e1 e1 ordered before e2 e2 ordered before e1

  11. Eu-teum Choi, DS Lab. Events and Races • Definition 6 • Fix an input to the program. Event e1is semi-ordered before event e2if for that input • Every execution where both e1and e2occur, e1  e2, • There exists an execution containing e1but not e2and • Every execution that contains e2also contains e1. e1 e1 e2 e2 Every execution or or e1 e2 Excution 1 Excution 2 Excution 1 Excution 2 e1 semi-ordered e2 e2 semi-ordered e1

  12. Eu-teum Choi, DS Lab. Events and Races • Definition 7 • Two events are unordered if they are neither ordered nor semi-ordered. e1 e1 e1 or e2 e2 Excution 1 Excution 2 e1 ordered before e2 e1 semi-ordered e2

  13. Eu-teum Choi, DS Lab. Events and Races • Definition 8 • Two simple statements conflict if they both access the same shared resource and on(or both) of the accesses modifies the resource. • The accesses can be explicit as in access to a shared variable or implicit as in a communication port used for message passing. e1 e2 modify modify Shared resource

  14. Eu-teum Choi, DS Lab. Events and Races • Definition 9 • Two different events that both occur in the same execution conflict if they represent the execution of conflicting simple statements. e1 conflict e2

  15. Eu-teum Choi, DS Lab. Events and Races • Definition 10 • Fix an input to the program. If two conflicting events are unordered then there is a race between the two events on the input e1 e1 e1 or Race e2 e2 Excution 1 Excution 2 e1 ordered before e2 e1 semi-ordered e2

  16. Eu-teum Choi, DS Lab. Events and Races • Definition 11 • A program contains a race between statements s1and s2 if there is an input and event e1 and e2such that: • e1represents the execution of an instance of s1, • e2represents the execution of an instance of s2, • s1and s2contain(or are) conflicting simple statements, and • There is a race between e1and e2on input  conflict S1 S2 e1 race e2

  17. Eu-teum Choi, DS Lab. Ordering properties of Races • When only a single input is considered, we can classify races based on the relationships between the two events in the various executions. • e1e2 • e2e1 • e1 and e2 overlap, • e1 occurs but e2 does not, • e2 occurs but e1 does not, • neither e1 nor e2 occur e1 e1 e2 e2 e1 e2 e1 e2 1 2 3 4 5 6

  18. Eu-teum Choi, DS Lab. Ordering properties of Races • Given six distinct elements there are 64(=26) distinct sets possible • Some of the 64 sets are not very interesting. • The presence of Case 6 execution, where neither event occurs, does not affect the existence of races.  32 (=25) • Two ordered events : 1 only and 2 only  32-2=30 • Two combinations describe semi-ordered events : 1with 4 and 2 with 5  30-2=28 • Three other combinations at least one of the two events is never executed : 4 only, 5 only and none of 1-5  28-3=25

  19. Eu-teum Choi, DS Lab. Ordering properties of Races • Four different kinds of races • Overlap race : e1and e2 are overlap • Concurrent race : (e1 and e2 are overlap ) & (e1e2or e2e1 ) • Unordered race : (e1 and e2 are not overlap ) & (e1e2 or e2e1 ) • Artifact race : (e1e2) & ( only e2 ) & (! (e1 and e2 are overlap ) or !(e2e1 ))

  20. Eu-teum Choi, DS Lab. Ordering properties of Races • Four different kinds of races • Overlap race : e1and e2 are overlap • Concurrent race : (e1 and e2 are overlap ) & (e1e2or e2e1 ) • Unordered race : (e1 and e2 are not overlap ) & (e1e2 or e2e1 ) • Artifact race : (e1e2) & ( only e2 ) & no execution (! (e1 and e2 are overlap ) or !(e2e1 )) “1” is printed “0” is printed “0” is printed

  21. Eu-teum Choi, DS Lab. Ordering properties of Races • General race • Overlap race • Occurrence : Two events interact in an unforeseen way • Solution : Mutual exclusion • Concurrent race • Similar to unordered races except that they indicate a total lack of sync. • Unordered race • Occurrence : Mutual exclusion

  22. Eu-teum Choi, DS Lab. Ordering properties of Races • Data race • The union of both overlap race & concurrent race • The events do overlap in some execution • Artifact race • Artifact race • Occurrence is The other races • and NO first race

  23. Eu-teum Choi, DS Lab. Other attributes of races • Control vsData • Control race : A thread to take different paths depending upon how the race is resolved. • Data race : If the control flow is not affected by a race. • Severity • Two severity levels, critical and benign. • A benign race has no external effect on the results of the program • Critical race can affect the program’s result • The two updates to x can happen in either order and thus create a race. However, the value of x is always three after both critical sections have been executed. • Unordered races are often benign when they are caused by commutative updates to a shared variable.

  24. Eu-teum Choi, DS Lab. Other attributes of races • Feasibility • Feasible : did not occur but does occur in another execution • Infeasible : any race that is reported but could never actually occur • This is really a characteristic of the race detection system which , in general, can only approximately identify races because detecting races is a very hard problem. • Software tool should never report a race as being infeasible.

  25. Eu-teum Choi, DS Lab. Conclusion • This paper have presented a classification of races that includes orthogonal attributes, event ordering, control versus data, severity and feasibility. • Race taxonomy is complete in that it encompasses all possible races. It also separates races into different categories based on the type of error that typically causes that kind of race

More Related