IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 Efficient Execution Path Exploation fo Detecting Races in Concuent Pogams Theodous E. Setiadi, Akihiko Ohsuga, and Mamou Maekaa Abstact Concuent pogams ae moe difficult to test o debug than sequential pogams because thei non-deteministic behavios can poduce eos that depend on timing and inteleaving of theads. A diffeent inteleaving might affect banch outcomes that can lead the execution path into one diffeent fom that in hich the eo as detected. In ode to detect concuent eos, a pogamme needs to e-execute the concuent pogam many times by changing the inteleaving, but it is not alays feasible to conduct all the tests due to a lage numbe of possible diffeent inteleavings. This pape poposes an efficient method to minimize the numbe of test cases fo detecting eos in a concuent pogam. This method geneates test cases ith diffeent inteleavings based on the execution tace. The method educes edundant test cases ithout sacificing the pecision of eo detection. The method is novel because it exploits the banch stuctue and utilizes data flos fom tace infomation to identify only those inteleavings that affect banch outcomes, heeas existing methods ty to identify all inteleavings that seem to affect shaed vaiables. In ode to educe the numbe of test cases, those execution paths ith equivalent lock sequences and accesses to shaed vaiables ae gouped togethe into the same ace-equivalent goup and only one membe of the goup is tested. We evaluated the poposed method against seveal concuent Java pogams. The expeimental esults fo a Java pogam fo telnet sho the numbe of test cases is educed fom 147, hich is based on the existing TPAIR method, to only 2 by the poposed method. Moeove, fo concuent pogams that contain infinite loops, the poposed method geneates only a finite and vey fe numbe of test cases, hile many existing methods geneate an infinite numbe of test cases. Index Tems ace detection, testing, concuent pogam A. Backgound C I. INTRODUCTION ONCURRENT pogams ae difficult to test o debug because thei non-deteministic behavios can poduce eos that depend on timing, such as ace conditions. It is suggested that ace conditions occu mostly because shaed vaiables ae accessed by theads using inconsistent locking o even no locks[1] [5]. Pogammes often fail to apply Manuscipt eceived August 25, 2012; evised June 22, 2013. T. E. Setiadi is ith the Gaduate School of Infomation Systems, Univesity of Electo-Communications, Tokyo, Japan. The autho as suppoted by the JINNAI intenational student scholaship. (phone +81-90-4171-9071; e-mail eic@maekaa.is.uec.ac.jp). A. Ohsuga is ith the Gaduate School of Infomation Systems, Univesity of Electo-Communications, Tokyo, Japan. (e-mail akihiko@ohsuga.is.uec.ac.jp). M. Maekaa is ith the Gaduate School of Infomation Systems, Univesity of Electo-Communications, Tokyo, Japan. (e-mail maekaa@maekaa.is.uec.ac.jp). appopiate locks due to difficulties in pedicting the execution path o inteupt timing because of the complexity of concuent pogams, especially hen banches ae affected by access to shaed vaiables and inteleavings. To detect ace conditions, a pogamme can execute the concuent pogam and check the execution tace using a dynamic ace detecto. Unfotunately, concuent eos might not be easy to detect because a e-executed concuent pogam might execute ith a diffeent inteleaving. Adding additional commands o instumentation of the souce code to ecod intemediate esults fo testing concuent pogams might change the inteleaving, so that eos may not sho up. Unfotunately again, dynamic ace detectos can detect potential eos only if they sho up in a e-execution. In this pape, e popose a ne, efficient dynamic method to minimize the numbe of test cases fo detecting concuent eos. This is an impovement ove the existing method [11]. Ou poposed method iteatively uses pevious execution taces as guidance fo geneating ne test cases. The method is paticulaly intended fo situations in hich concuent eos ae difficult to detect. The numbe of executions needed fo testing is the numbe of possible inteleavings of the concuent pogam. Even hen the input values ae fixed, the numbe of executions is still vey lage. The main poblem is ho to educe this numbe of e-executions. The contibutions of this pape ae as follos Eliminating edundant test cases The poposed method educes the numbe of inteleavings to be tested by exploiting the banch coveage infomation fom the execution tace. This method is diffeent fom pevious methods because it can distinguish those inteleavings that can affect banch outcomes fom those that cannot. The existing eachability testing algoithms ty to identify all inteleavings hich may affect shaed vaiables, although they may not necessaily affect banch outcomes; thus edundant inteleavings ae included. These edundant inteleavings ae, hoeve, educed in ou method, esulting in a significant eduction in the numbe of inteleavings fo testing. Eliminating infeasible test cases The existing eachability testing algoithms do not conside the synchonization event dependency of the execution path, e.x. lock-unlock and ait-notify mechanisms. Thee exist infeasible inteleavings due to this dependency. The poposed method extends the existing model of vaiant gaphs to identify infeasible inteleavings due to this dependency, theeby futhe contibuting to educing the numbe of test cases. (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 CS 1 CS 2 B. Motivation Thead T1 x y banch dependent dependent Thead T2 CS A CS B Fig. 1. Example of gouping fo inteleaving. loop Seveal methods have been poposed to educe the numbe of inteleavings that need to be tested. Patial ode eduction is a geneal method hich consides only those inteleavings that may affect an execution of a pogam based on cetain citeia. One example of the patial ode eduction method educes the numbe of inteleavings by consideing only those that may affect the values of shaed vaiables [12] [13] [14] and by ignoing the ode of independent opeations, hee to opeations ae said to be independent if any diffeent ode of the opeations does not affect the values of shaed vaiables. An example of independent opeations is to ead opeations fom diffeent theads accessing the same shaed vaiable. Such inteleaving is left unodeed because its ode is ielevant to the esulting values of any shaed vaiables. Unfotunately, such patial ode eduction still leaves some edundancy hen exploing diffeent execution paths in a thead fo detecting potential ace conditions. Conside the example in Fig. 1. In the case that the loop in the thead T2 is executed only once, thee ae six possible diffeent inteleavings. The fist and the second inteleavings ae diffeent only in the ode of independent opeations, so they ill have the same values fo shaed vaiables. A simila situation happens fo the fifth and sixth inteleavings. By ignoing the ode of independent opeations, thee ill be only fou goups of inteleavings ith diffeent combinations of values fo the shaed vaiables x and y. Fo membes of the same goup, the same ead o ite opeation is guaanteed to use the same value of shaed vaiable. If the banch only depends on the shaed vaiable x, thee ae actually only to goups that matte fo changing the execution path of thead T1. These goups ae detemined by hethe CS 1 x is executed befoe CS A x (goup 1) o vice vesa (goup 2). When the loop in the thead T2 is executed seveal times o possibly becomes an infinite loop, thee ae moe possible inteleavings that affect the value of the shaed vaiable y, but still thee ae only to goups of inteleavings ith espect to diffeent values of the shaed vaiable x. We ill use this idea fo exploing diffeent execution paths efficiently. Fig 2 shos some possible execution paths fo an execution of a concuent pogam. A thead can take a diffeent execution path ith a diffeent lock sequence o diffeent accesses to shaed vaiables. To detect the x y goup 1 goup 2 goup 3 goup 4 Gouping by ignoing the ode of independent opeations. 1. CS 1 x, CS 2 y, CS A x, CS B y 2. CS 1 x, CS A x, CS 2 y, CS B y 3. CS 1 x, CS A x, CS B y, CS 2 y 4. CS A x, CS 1 x, CS 2 y, CS B y 5. CS A x, CS 1 x, CS B y, CS 2 y 6. CS A x, CS B y, CS 1 x, CS 2 y Only diffe in the ode of independent opeations. goup 1 CS 1 x befoe CS A x goup 2 CS A x befoe CS 1 x Gouping by consideing data dependency hen the banch only depends on shaed vaiable x concuent eos, e need to find all diffeent inteleavings that can change the execution path. Fig. 2. Example of some possible execution paths fo a concuent pogam. Suppose that path 1 is executed concuently ith path 3 (path 1 path 3) hen the pogam is fist tested. In this case, thee ae thee possible diffeent inteleavings 1. CS A x, CS 1 x, CS 2 x 2. CS 1 x, CS A x, CS 2 x 3. CS 1 x, CS 2 x, CS A x Refeing to Fig 2, let us assume that the fist inteleaving is taken hen the pogam is fist tested. The othe to inteleavings ae othe possible test cases. Assuming that the banch is conditioned by the shaed vaiable x, the conditional statement of the banch is only affected by the ode of CS A x and CS 1 x. In this example, CS 1 x is executed befoe CS A x in the second and the thid inteleavings, so they ill esult in the same execution path fo thead T1, that is eithe path 1 o path 2. Since thead T1 follos the same execution path in the second and thid inteleavings, this ill not change the consistent locking among theads. In othe ods, the same lock sequences and accesses to shaed vaiables ae held. If the banch condition is tue, then both the inteleavings ill lead to the execution of path 1 concuent ith path 3 (path 1 path 3). On the othe hand, if the banch condition is false, then e ill have the combination of the execution of path 2 concuent ith path 3 (path 2 path 3). Fo exploing diffeent execution paths in thead T1 caused by the banch, e need only test one of the inteleavings, that is eithe the second o thid inteleaving. By consideing the dependency beteen the conditional statement in the banch and the shaed vaiables, e can avoid testing inteleavings that do not change the execution path of a thead. Fo the example in Fig 2, if e kno fom the pevious executions that the banch is not affected by the (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 shaed vaiable x, then thee is no need to test the second o the thid inteleaving. Of couse, the final esult fo the value of the shaed vaiable x can be diffeent in the second and thid inteleavings because it might also depend on the ode of CS A x and CS 2 x. If the execution path in thead T1 changes to path 2, e compae the locking fo accesses to shaed vaiables beteen CS 2 and CS 3 befoe checking the ace conditions fo the concuent execution of path 2 and path 3 (path 2 path 3). If the locking fo accesses to shaed vaiables in CS 2 and CS 3 is the same o equivalent, then the ace conditions ae the same as in the fist test case (path 1 path 3) in the pevious execution, thus educing the effot fo checking ace conditions. II. RELATED WORK Eo detection can be classified into static and dynamic methods. Static methods only employ souce code analysis at compile time ithout executing the pogam. Since static methods do not kno the pecise execution of a pogam that causes the eo, they use a consevative appoach by consideing all possible executions in ode not to ovelook potential eos [39]. Static methods ae moe suitable fo testing because they check all possible pogam behavios. Fo debugging, static methods often suffe fom the detection of false positives; that is, potential ace conditions that do not actually exist in the execution. Dynamic methods [15] [17] execute the pogams and detect eos using infomation fom the execution of the pogam, including the execution tace and souce code infomation. Fo the puposes of debugging, dynamic methods ae moe suitable than static methods because they can pefom moe pecise eo detection by employing the execution tace. Thee ae some execution tace analysis techniques that use lockset analysis [1] [16] [37] fo dynamically detecting ace conditions. They veify hethe an execution of a pogam satisfies a locking discipline. Fo example, Ease [1] is a lockset analysis that identifies a ace condition fom a paticula execution by checking the consistency of locking fo accesses to shaed vaiables. Most eseach in this field is focused on educing false positives [15] [35] [39] [43] and educing the oveheads caused by tacing [30] [38]. J. Huang, J. Zhou, and C. Zhang [38] identified one of the causes of edundancy to be that an execution tace often contains a lage numbe of events that ae mapped to the same lexical statements in the souce code. Hoeve, emoving them ithout caeful analysis might cause false negatives because they might affect the epoduction of ace conditions. This situation happens hen a numbe of events fom the same lexical statement in the souce code affect a conditional statement in a banch hose then and else statements have a diffeent lock sequence and accesses to shaed vaiables. In othe ok by C. Pak, K. Sen, P. Hagove, and C. Iancu [40], knon as active testing, impecise dynamic analysis of an execution tace is pefomed to geneate a set of tuples that epesents potential concuent eos. In the late phase, it e-executes the pogam by actively contolling the thead schedule to confim the concuent eos. Hoeve, thee might be some false negatives fo detecting ace conditions because the set of tuples might be incomplete if some tuples ee not executed in the execution. This situation happens hen a ace condition is caused by the then o else statements of a banch hose conditional statement is affected by inteleaving. Race conditions can only be detected using dynamic methods if the execution tace contains the potential concuent eos. Unfotunately in a concuent pogam, a banch can take a diffeent execution path not only due to diffeent input values, but also due to diffeent inteleavings. Hence, depending on the banches and inteleavings, an execution tace might o might not contain potential ace conditions. Deteministic eplay techniques ae available fo eplaying an execution of a concuent pogam ith the same inteleaving. Such techniques ecod the concuent execution tace in a ecoding mode. The ecoded execution can be eplayed late in a eplaying mode fo dynamic analysis. A commecial tool fo deteministic eplay [27] is capable of epoducing the oiginal execution ode of theads, thus the same inteleaving can be eplayed. When a concuent eo is detected duing a ecoding mode, a deteministic eplay equies only one execution to eplay the eo and obtain the execution tace containing the eo. This is useful fo debugging concuent pogams. Hoeve, this is only effective if pogammes can identify the eos hen a concuent pogam is unning in ecoding mode duing softae development o a testing cycle. Unfotunately, due to the huge numbe of all possible inteleavings, not all of them can be tested duing softae development o the testing cycle because of time and cost estictions. Sometimes only egession tests ae pefomed afte fixing bugs and the softae is quickly deployed in eal situations, leaving the possibility that othe eos emain. In ecoding mode, all the infomation necessay fo eplaying can be taced using instumentation [7] o a specialized vitual machine [6]. Hence, pogams un moe sloly duing ecoding mode and equie moe memoy to stoe infomation about inteleaving and pogam states. This is knon as the pobe effect. Theefoe, executions cannot alays be taced duing the deployment of systems that equie high pefomance o hee esouces ae limited, such as in embedded systems. To educe the pobe effect, a special hadae device can be used to communicate ith the pefomance monito though JTAG (efe to IEEE 1149) fo tacing, but many hadae constuctions cannot un at full speed hen JTAG is used [33]. The advantage of this appoach is that an execution can be taced ith minimum intefeence, but the daback is expensive hadae costs. In cases hen an eo has happened in the absence of a complete execution tace fo eplaying, pogammes need to test the concuent pogam ith tacing to see if the same eo can be detected. Unfotunately, the eo might not be easy to detect because a concuent pogam can have a diffeent inteleaving duing e-execution. In this situation, pogammes need to contol the inteleaving and use deteministic testing. Deteministic testing can enfoce a paticula inteleaving specified in test cases. Since the numbe of possible diffeent inteleavings can be huge, the method poposed in this pape helps in the efficient (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 geneation of test cases to epoduce the same o equivalent execution conditions. Some tools fo deteministic eplay can also be used fo deteministic testing. Fo example, in Jeplay [7] pogammes can contol the inteleaving by enfocing thead sitching using some additional locks, and can ite them in the locations hee a thead sitch should occu. Enfocing a thead sitch is ealized by unblocking the next thead in the schedule folloed by blocking all othe theads, including the cuent thead. An additional lock object is assigned to each thead. The ait and notifyall methods ae used to implement the block and unblock opeations that suspend and esume an execution of a thead. A binay semaphoe is used to pevent deadlocks in the contol tansfe method due to inteceptions by the JVM schedule. Anothe method devised by Pugh and Ayeah [36] uses a clock to synchonize the ode of executions in multiple theads. Pogammes can delay opeations ithin a thead until the clock has eached a desied tick. Detemining hich of all the possible inteleavings ae necessay is impotant because it diectly affects the efficiency of test case geneations. Basically, thee ae thee appoaches 1. Random inspect only some of all the possible inteleavings using andomizing o noise injection. 2. Patial inspect only some of all possible inteleavings based on cetain citeia. 3. Exhaustive inspect all possible inteleavings. Random appoaches might not discove eos because only some of the possible execution paths ae inspected. An impoved andom appoach uses a heuistic appoach [18] to educe the seach space. Anothe impovement - caied out in ConTest - uses coveage to guide the heuistic test geneation [2], but still does not ensue that eos ill be found because not all possible execution paths ae tested. Basically, finding eos equies an exhaustive appoach. Unfotunately, exhaustive appoaches often suffe fom an explosion of the numbe of possible execution paths to be inspected. The idea behind a patial appoach is to identify a goup of execution paths ith the same coveage. Fo each paticula goup, it is sufficient to test only one goup. In pogam testing, the coveage citeion states ho much of the pogam execution space is to be coveed duing testing. We can identify five levels of citeia based on pogam stuctue [8]. These ae statement coveage, node coveage, banch coveage, multiple condition coveage, and path coveage. Statement coveage and node coveage ae athe eak citeia, epesenting necessay but by no means sufficient conditions fo conducting a easonable test. Banch coveage and multiple condition coveage ae stonge citeia. Path coveage is the most thoough of all, and it is necessay to ensue the coectness of a pogam by testing o to find eos in debugging. Hoeve, it is nomally difficult to achieve, paticulaly in a concuent pogam, because the numbe of possible execution paths might be huge. Nevetheless, since diffeent execution paths might execise diffeent lock sequences and accesses to shaed vaiables that can affect consistent locking, it is necessay to adopt path coveage to ensue that all concuent accesses to shaed vaiables ae consistent. In the field of concuent pogams, thee exist some othe citeia besides stuctual coveage that can help to detemine hich inteleavings should be tested. Fo example, CHESS [19] geneates all inteleavings of a given scenaio itten by a teste based on fai scheduling. Anothe appoach [20] exhaustively geneates all possible execution odes fo test cases fo the pupose of mitigating memoy consumption poblems by dynamically building patitions along the taces. Thee is also a coveage model fo evaluating concuent completeness. Synchonization coveage [9] coves diffeent odes of synchonization events fom diffeent theads. Its goal is to check hethe the synchonization statements have been popely tested. Fo example, the tylock method of the Lock inteface in Java 1.5 is used to check hethe a lock is available. It does not block, but may succeed o fail depending on hethe anothe thead is holding the lock. If it alays succeeds o alays fails, then eithe the tests ae sufficient o the opeations ae edundant. Anothe appoach uses pogam flo as a coveage citeion fo examining an execution of a pogam. All-du-path coveage [10] uses define-use associations and is applicable fo paallel pogams. Synchonization coveage and All-du-path coveage ae not suitable citeia fo checking consistent locking among theads conside cases hee only the ode of the ty-locks is diffeent fo synchonization coveage o thee ae diffeent define-use associations fo All-du-path coveage, but lock consistency is not changed. In these cases, all possible concuent lock-unlock sequences and accesses to shaed vaiables may not be coveed. The ok done by Koushik Sen and Gul Agha [44] [45] is intended to facilitate the exploation of diffeent execution paths. Thei tool, called JCute, exploes execution paths by geneating ne inteleavings as ell as ne input. It geneates all possible inteleavings based on pevious executions by changing the ode of thead executions, stating fom the smallest indexed thead. Redundancy is still pesent hee, because not all inteleavings ould change banch execution and locking, as peviously shon by the example in the Motivation subsection III. OVERVIEW OF THE EXISTING REACHABILITY TESTING METHOD This section explains an existing method fo geneating test cases fo concuent pogams using the eachability testing method [11] [21] [22]. This is a dynamic method that uses patial ode eduction fo educing test cases. The eachability testing method in [11] coves all diffeent inteleavings that affect the values of shaed vaiables as test cases. This eachability testing uses the pevious execution tace to deive diffeent ead-ite sequences that affect values of shaed vaiables. Assume that S is a ead-ite sequence fom an execution of a concuent pogam. The concept of eachability testing is defined as follos 1. Use S to deive othe ead-ite sequences, called execution-vaiants, that poduce diffeent values of shaed vaiables. 2. Pefom deteministic testing based on the esult fom step 1 using tacing. (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 3. Fo each ne execution-vaiant fom step 2, epeat step 1 and 2 until no moe execution-vaiants ae found. Vaiant Gaph The eachability testing method pefoms an efficient exploation of execution-vaiants by gouping and ignoing diffeent inteleavings that do not affect values of shaed vaiables, using the idea of patial ode eduction. Test cases ae geneated systematically using a vaiant gaph. A vaiant gaph deives diffeent ead-ite sequences fom the pevious execution tace. A diffeent ead-ite sequence that affects the values of shaed vaiables is called an execution-vaiant. Execution-vaiants ae used as test cases in eachability testing. Algoithm 1 shos ho to ceate a vaiant gaph fom an execution tace of a concuent pogam. Algoithm 1. Ceating a vaiant gaph. Definitions - S(j) is a ead-ite sequence fo thead Tj. - S(j, i) is the i-th opeation in the sequence of thead Tj. Each node N in the execution-vaiant gaph contains the folloing to vectos - index vecto (id 1, id 2,, id p ), hee p is the numbe of theads and id j indicates the i-th opeations in a thead Tj hen node N is geneated. The index vecto is initialized to zeo and inceased by one afte each ead o ite opeation in the thead Tj. - vesion vecto (ve 1, ve 2,, ve q ), hee q is the numbe of shaed vaiables and ve k is the vesion numbe of vaiable Vk hen node N is geneated. The vesion fo vaiable Vk is initialized to zeo and inceased by one afte each ite opeation to the vaiable Vk. Input ead-ite sequence. Output vaiant gaph. Step 1. Initialize the vaiant gaph. Ceate an initial node and label it as unmaked. Set its index vecto to (0,0,, 0) and vesion vecto to (0,0,, 0). Step 2. Deive diffeent ead-ite sequences. 2.1 Select an unmaked node, say N. Fo each j, 1 j p, hee p is the numbe of theads If id j < the length of S(j), Then constuct a child node N of N accoding to steps 2.2 2.5. 2.2 Set the index vecto of N to that of N except that the j-th element is id j + 1. 2.3 Set the vesion vecto of N to that of N. 2.4 Let va k be a shaed vaiable in the opeation S(j, id j +1) and ve k is the vesion numbe of vaiable va k in S(j, idj +1). 2.5 If S(j, idj +1) is a ite opeation to shaed vaiable va k, Then incease the ve k of N by 1. Step 3. Identify an execution-vaiant. 3.1 Let ve k be the k-th element of the vesion vecto of N. 3.2 If ve k!= ve k Then label N as maked and execution-vaiant (V). Else If the vaiant gaph aleady contains a node ith the same index and vesion vecto as N. Then label N as maked Else label N as unmaked Step 4. Repeat step 2 until all nodes in it ae labeled maked. Do not ceate child nodes fo the nodes hich ae labeled as execution-vaiant (V), as this ill be done late by executing them as test cases. Note that e fist need to identify all shaed vaiables fom souce code befoe ceating a vaiant gaph. If e do not conside all shaed vaiables, then late e might need to econstuct the vaiant gaph hen othe vaiables ae found to be shaed. It is not enough just to identify shaed vaiables fom the execution tace because maybe not all shaed vaiables can be detected fom a paticula execution tace. Unfotunately, it is not alays possible to identify pecisely all shaed vaiables fom souce code in the case that theads ae dynamically ceated accoding to input data, fo example, it is necessay to conside all potential shaed vaiables. If some vaiables ae not actually shaed, they ill lead to edundant nodes in a vaiant gaph, but they ill not poduce edundancy in test cases because they ill not lead to any ne execution-vaiants. Model fo Concuent Pogam Execution Taces A concuent pogam execution tace contains a sequence of opeations fom all the theads. An opeation in a thead is modeled as a tiplet of location opeation opeand, hee location is thead_namefile_nameline_of_code. The thead name o the file name is omitted in some cases fo simplicity hen thee is no ambiguity. opeation is the ead o ite opeation on a shaed vaiable. opeand is the name of the shaed vaiable. Fig 3 shos an example of a concuent pogam and its flo gaph. Let us assume that the folloing ead and ite sequence S is obtained fom an execution tace of the fist test T11 ead x, T210 ite x, T11 ead y, T11 ite n, T12 ead n, T211 ite y, T13, T17 ead y, T212 ead x. Fig.4 is an example of a vaiant gaph constucted using Algoithm 1 fo the execution tace above. Lined boxes in a vaiant gaph epesent possible ead-ite sequences hee they access the same values of the shaed vaiables as in the pevious execution. A dotted box in a vaiant gaph epesents an execution-vaiant (V) in hich some ead o ite opeations access values of shaed vaiables diffeent fom the pevious execution as a esult of a diffeent inteleaving. Thee ae seven execution-vaiants V1, V2, V3, V4, V5, V6, and V7 in Fig. 4. Fig 4 shos to equivalent ead-ite sequences suounded by dotted lines. They ae equivalent in tems of the ead-ite sequence, in the sense that evey opeation ill ead o ite the same vesions of shaed vaiables. The eachability testing algoithm [11] pefoms eduction by only consideing one of them as an execution-vaiant. (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 Thead T1 1 n = x + y; 2 if (n<0) { 3... 4 } else { 5... 6 } 7 pint y; Thead T2 10 x = -10; 11 y = 2; 12 pint x; T Thead T1 1 n = x + y 2 if (n<0) 3... 5... 7 pint y F Thead T2 10 x = -10 11 y = 2 12 pint x T Thead T1 1 ead x 1 ead y 1 ite n 2 ead n 3... 5... 7 ead y F Thead T2 10 ite x 11 ite y 12 ead x; (a) Fig. 3. (a) Example of a concuent pogam (b) Flo gaph. (c) Flo gaph fo ead and ite opeations. (b) (c) T17 ead y V1 3, 0 0,0 0,0 0,0 Note T11 ead x T210 ite x T1 T2 index 1, 0 x y vesion T11 ead y 0, 0 T210 ite x 0, 1 T11 ead x T211 ite y 2, 0 1, 1 T211 ite y 1, 1 0, 2 0, 0 V5 1, 2 T11 ead y T210 ite x T11 ead x T212 ead x 2, 1 2, 1 T11 ead y T212 ead x 1, 2 2, 2 1, 3 0, 3 V3 1, 1 T211 ite y T17 ead y V6 2, 2 T11 ead y T11 ead x 3, 1 2, 3 1,3 V4 T17 ead y T212 ead x V2 3, 2 2, 3 Note V7 T212 ead x T17 ead y execution-vaiant Fist eexecution 3, 3 3, 3 Equivalent ead-ite sequence Fig. 4. Example of a vaiant gaph fom an execution tace. IV. PROPOSED METHOD Fist, the folloing essential tems ae defined. A. Tems Execution Path A concuent pogam consisting of theads T1, T2, T3,, Tp, hee p is the numbe of theads. An execution path is defined in the scope of a thead and a concuent pogam An execution path Pi of a thead Ti is a sequence of opeations executed by the thead Ti. Fo the execution of the pogam shon in Fig. 6(a) and Fig. 6(b), e have P1 = {10 if ( ), 11lock a, 12 ead x, 13 unlock a} P2 = {20lock a, 21lock b, 22ead y, 23ite x, 24unlock b, 25unlock a } A concuent execution path of a concuent pogam is defined to be a sequence of opeations executed by all theads, taking into account the global ode among theads. Fig. 6 shos fou possible examples of concuent execution paths fo the concuent pogam in Fig.5. We define PATHS as a set of execution paths Pi s. PATHS = (P1, P2, P3,, Pp), hee p is the numbe of theads. Note that PATHS does not take into account the global odeing among theads. Fo the example in Fig. 6(a) and Fig. 6(b), e have (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 conditional statement banch b then-statements else-statements Fig. 5. Example of an if-statement. Thead T1 10 if( condition ){ 11 lock a 12 ite x 13 unlock a 14 } else{ 15 ite x 16 } 24unlock b, 25unlock a } }. Thead T2 Access to shaed vaiable x ithout peviously acquiing any locks. 20 lock a 21 lock b 22 ead y 23 ite x 24 unlock b 25 unlock a PATHS = { P1, P2 } = { {10 if ( ), 11lock a, 12 ead x, 13 unlock a}, {20lock a, 21lock b, 22ead y, 23ite x, 24 unlock b, 25 unlock a} } Inteleaving and Banching We denote by b i,j the j-th banch of thead Ti in the execution path of thead Ti. The tuth value of a conditional statement in a banch can be affected by both input values and inteleaving because inteleaving might affect shaed vaiables, hich may in tun affect the conditional statement. Fig. 6(a) and Fig. 6(b) sho some possible concuent execution paths fo the pogam in Fig. 5 hen the conditional statement in the banch b is tue, heeas Fig. 6(c) and Fig. 6(d) sho the concuent execution paths hen the conditional statement is false. Let denotes the happens-befoe elation as follos If a is an event in pocess Pi, and b is an event in pocess Pj, then event a event b if and only if event a happens befoe event b. In the example of Fig. 6, the ode of T110 and T223 affects the tuth value of the banch b. The banch is tue in executions 1 and 2 hen T110 T223, and false in executions 3 and 4 hen T223 T110. We ill late explain ho to identify opeations that affect a banch. Race Condition Consistent locking fo accessing a shaed vaiable means thee is at least one lock hich is alays acquied by all theads befoe accessing this shaed vaiable. Such locks ae called consistent locks. An access to a shaed vaiable is said to be ell fomed if all theads acquie a consistent lock befoe accessing the shaed vaiable, and then pefom an unlock opeation to elease the coesponding lock. In concuency contol using a lock mechanism, a ace condition exists hen access to a shaed vaiable is not ell fomed. Detecting ace conditions is checking consistent locking fo accessing shaed vaiables. A ace detecto called Ease [1] poposes an efficient algoithm fo checking consistent locking in the execution of a concuent pogam. In concuency contol using a lock mechanism, it is the esponsibility of pogammes that a pope lock opeation is pefomed befoe accessing a shaed vaiable, and that the lock is eleased afte the access to the shaed vaiable has been completed. Thee ae vaious easons hy access to a shaed vaiable may not be ell fomed fo example, pogammes may foget to ite the lock, they may ite an incoect lock, o they may make an incoect pediction about the execution path, esulting in the lock not being popely set. An example is shon in Fig. 6(c) and Fig. 6(d) hee the "else-statements" in line 15 fo thead T1 access the shaed vaiable x ithout acquiing any locks. Anothe eason that an access may not be ell fomed is that pogammes may intentionally omit a lock fo pefomance easons hen data ace ae acceptable, fo example by using a volatile vaiable in Java. In those cases, the access to shaed vaiables is not ell fomed and a ace condition is caused. Access-Manne We divide an execution path of a single thead into seveal pats called access-mannes. Late e ill sho that access-manne is useful to define equivalency in tems of ace condition among diffeent executions of a concuent pogam, even though they do not have the same exact sequence of locks and accesses to shaed vaiables. In ode to define access-manne, e use notation L(Ti) as the numbe of active locks acquied by thead Ti at a paticula time. At the beginning of the execution of thead Ti, L(Ti) is 0. Duing an execution of a pogam, L(Ti) is incemented and decemented by the folloing ules Incemented by 1 hen a thead successfully acquies a lock (i.e. has completed a lock instuction). Decemented by 1 hen a thead eleases the lock (i.e. has completed an unlock instuction) that is cuently acquied. L(Ti) is not decemented if a thead is tying to elease a lock that is not cuently acquied. Hence L(Ti) cannot be negative. Most ace conditions occu because pogammes use an incoect lock o even foget to acquie a lock befoe accessing shaed vaiables. Fo checking hethe the usage of a lock as coect, e use the tem access-manne hen the access to a shaed vaiable is pefomed unde a lock. We define an access-manne as a sequence of opeations in hich a thead has acquied a lock, has accessed a shaed vaiable, and has eleased the coesponding lock. An individual access-manne is usually a sequence of lock-unlock and ead-ite opeations to shaed vaiables ithin a thead s execution path that stat and end ith the folloing conditions Stat lock opeation that causes L(Ti) to become 1. End unlock opeation that causes L(Ti) to become 0, o hen execution tace teminates. An individual access-manne must end befoe anothe individual access-manne stats and thee must not be ovelaps beteen access-mannes. In the case hee pogammes foget to acquie a lock, it is knon as an unusual access-manne hen an access to shaed vaiables ithout acquiing a lock stats, o hen pogammes only ite an unlock ithout peviously acquiing the lock. (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 time Execution 1 b is Tue T110 if ( ) { T111 lock a T112 ite x T113 unlock a T220 lock a T221 lock b T222 ead y T223 ite x T224 unlock b T225 unlock a (a) Execution 2 b is Tue T220 lock a T221 lock b T110 if ( ) { T111 lock a T112 ite x T113 unlock a T222 ead y T223 ite x T224 unlock b T225 unlock a (b) Execution 3 b is False T220 lock a T221 lock b T222 ead y T223 ite x T110 if ( ) { T114 } else { T115 ite x T224 unlock b T225 unlock a Fig. 6. Example of diffeent concuent execution paths fo pogam in Fig. 5. Execution 4 b is False T220 lock a T221 lock b T222 ead y T223 ite x T224 unlock b T225 unlock a T110 if ( ) { T114 } else { T115 ite x Thead T1 is accessing shaed vaiable x ithout peviously acquiing any locks. (c) (d) stat lock, L(T2)=1 end lock, L(T2)=0 stat ite, L(T1)=0 end ite, L(T1)=0 In such a case, access-manne is defined as one opeation of unlock, ead o ite to a shaed vaiable. Such an unusual access-manne might potentially cause a ace condition if anothe thead is accessing the same shaed vaiable. To individual access-mannes ae the same if they have the same sequence of lock-unlock statements and ead-ite opeations on shaed vaiables. We define Mi to be a set of access-mannes fo the execution path of thead Ti, that is a collection of distinct individual access-mannes ithout consideing thei ode. We also define a concuent set of access-mannes MANNERS = {M1, M2, M3,..., MN} as a collection of sets of access-mannes fom all the theads ithin a concuent execution path of a concuent pogam. When to concuent execution paths of a concuent pogam have the same MANNERS, each thead ill have the same set of access-mannes. When to diffeent concuent execution paths of a concuent pogam have the same PATHS, each thead in the to execution paths ill execise exactly the same sequence of lock-unlock and ead-ite opeations on shaed vaiables, hence they ill also have the same set of access-mannes. Theefoe, to concuent execution paths ith the same PATHS ill cetainly have the same MANNERS. The concuent execution path in Fig. 6(a) and the execution path in Fig. 6(b) have the same PATHS, hence they ill also have the same MANNERS M1 = {(11lock a, 12ite x, 13unlock a) } M2 = {(20lock a, 21lock b, 22ead y, 23ite x, 24unlock b, 25unlock a) } MANNERS = { {(11lock a, 12ite x, 13unlock a)}, {(20lock a, 21lock b, 22ead y, 23ite x, 24unlock b, 25unlock a)} } Race-Equivalent Regading epoducing ace conditions due to inconsistent locking fo accesses to shaed vaiables, it is beneficial to conside equivalency beteen to executions of a concuent pogam. Fo this pupose, e intoduce a ne tem called ace-equivalence. To executions of a concuent pogam ae ace-equivalent if they have the same MANNERS. Race-equivalent means the to concuent execution paths of a concuent pogam have the same consistent locking fo accessing shaed vaiables. Diffeent concuent execution paths of a concuent pogam that ae ace-equivalent ae said to be in the same ace-equivalent goup. It is sufficient to test only one membe fom each ace-equivalent goup, theeby educing the numbe of inteleavings to be tested. Fo detecting ace conditions, e need to check all ace-equivalent goups. As explained above, to concuent execution paths ith the same PATHS ill cetainly have the same MANNERS. Theefoe, to concuent execution paths of a concuent pogam that have the same PATHS ill cetainly be ace-equivalent. As shon befoe, the execution path in Fig. 6(a) and the concuent execution path in Fig 6.(b) have the same PATHS, so they ae ace-equivalent. We can see that lock a is a consistent lock fo accessing shaed vaiable x in both concuent execution paths. Diffeent ace-equivalent goups can be ceated by taking a diffeent concuent execution path in hich at least one thead changes its individual access-manne. A banch might lead to a diffeent concuent execution path hich, in tun, can poduce diffeent individual access-mannes that can affect consistent locking. As shon in the concuent execution paths in Fig. 6(c) and Fig. 6(d), thee is a ace condition because thee is no consistent lock fo access to shaed vaiable x in thead T1 M1 = {(15ite x) } M2 = {(20lock a, 21lock b, 22ead y, 23ite x, 24unlock b, 25unlock a) } MANNERS = {{( 15ite x) }, {(20lock a, 21lock b, 22ead y, 23ite x, 24unlock b, 25unlock a) } } To detect this ace condition, e need only check the concuent execution path in Fig. 6(c) o the one in Fig. 6(d) because they ae ace-equivalent. The same inconsistent locking can be detected. When a banch changes the execution path of a thead, it might not necessaily poduce diffeent consistent locking. In this situation, the same thead in the to concuent execution paths might not execise exactly the same lock-unlock sequence and ead-ite opeations on shaed (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 vaiables, but they ill still have the same MANNERS, and so e can also classify them as ace-equivalent. This is paticulaly useful in the case of loops because e do not need to test all the iteations. It is sufficient to test only a patial execution tace fom seveal iteations fo checking ace conditions because the execution of loop iteations can have the same access-mannes. In Fig. 7, thead T1 in execution 1 and execution 2 has diffeent access-mannes, hence concuent execution paths 1 and 2 ae not ace-equivalent. When thee is an active lock that as acquied outside the loop, then the fist iteation ill have diffeent access-mannes fom those in the second iteation because they stat fom diffeent active locks, as shon in concuent execution paths 1 and 2 in Fig. 7. On the othe hand, concuent execution paths 2 and 3 in Fig. 7 ae ace-equivalent because each thead in the to executions has the same MANNERS M1 = { (1lock a, 3ite x, 4unlock a), (3ite x), (4unlock a) } M2 = { (20lock a, 21ead x, 22unlock a) } MANNERS = {{(1lock a, 3ite x, 4unlock a), (3ite x), (4unlock a)}, {(20lock a, 21ead x, 22unlock a)}} The second iteation fo the loop accesses the shaed vaiable x ithout peviously acquiing any lock, a fact that can be detected in eithe concuent execution path 2 o 3. When thee is no active lock at the end of a loop, the est of the iteations ill have the same set of access-mannes. The est of these iteations ae called equivalent iteations in tems of consistent locking because they have the same set of access-mannes. Futhe to the discussion above, the poblem fo detecting a ace condition can be stated as follos Given a concuent pogam that has an execution-vaiant V eo containing an eo in its concuent set of access-mannes MANNERS eo, find the V eo, o anothe execution-vaiant V, hich has the same concuent set of access-mannes as MANNERS eo. Since each thead in V and V eo ill have the same set of access-mannes, then the same inconsistent locking and impope lock-unlock sequences in V eo ill also be detected in V. B. Reduction in the Numbe of Diffeent Inteleavings The numbe of diffeent inteleavings is educed by tying to ceate only inteleavings that lead to a diffeent ace-equivalent goup. This subsection explains ho to ceate diffeent ace-equivalent goups efficiently. The basic idea is that, fo exploing possible diffeent concuent execution paths caused by banches, it is sufficient to ceate and test only those inteleavings that might affect the conditional statements of banches. Diffeent execution-vaiants fom a paticula banch b might lead to the same value fo the condition. Hence, in exploing diffeent concuent execution paths caused by the banch b, e can educe test cases by gouping those execution-vaiants and testing only one membe fom each goup. We name such a goup a banch-affect goup. Execution-vaiants ithin the same banch-affect goup fo a banch b ill have the same condition value fo the banch b. Let BanchRelOP(b) be the set of ead and ite opeations on shaed vaiables that affect the condition of a banch b. The idea fo gouping the execution-vaiants comes fom the fact that if to execution-vaiants execute the same sequence of ead and ite opeations fom BanchRelOP(b), then they ill give the same condition value fo the banch b, and thus they can be gouped into the same banch-affect goup. To o moe execution-vaiants in the same banch-affect goup fo a banch b ae edundant ith espect to exploing the diffeent concuent execution paths caused by the banch b. Detemining the Set of Opeations that Affect Banch Outcomes In ode to identify "banch-affect goups, e fist need to detemine the set of opeations that affect the conditional value of a paticula banch b. We popose a data flo analysis method to identify opeations that affect the conditional statement of the banch b fom an execution tace. This method analyzes data flo among accesses to shaed vaiables elated to the conditional statement of the banch b. Based on this analysis, e can detemine hich opeations ae affecting the condition. One existing method fo data flo analysis is by using use-define. We use use-define to find opeations that affect conditional statements in banches. Fist e identify the use-define set SetUD hich e ill use fo gouping diffeent inteleavings. In sequential pogams, a use-define is a elation consisting of a use, U, of a vaiable, and the definitions, D, of that vaiable that can be eached fom that use ithout any othe intevening definitions. A definition can have many foms, but is geneally taken to mean the assignment opeation of some value to a vaiable. A use geneally means a ead opeation on a vaiable. A use-define is a tiplet (vaiable_name, use_location, define_location). R. Caballeo, C. Hemanns, and H. Kuchen [23] utilize use-define fo measuing test coveage but that definition does not apply to concuent pogams. We call the use-define fo sequential pogams the conventional use-define. Yang, A.L. Soute, and L.L. Pollock [10] [34] extended the definition and notation of use-define to cove possible usages and definitions of shaed vaiables in concuent pogams. They then poposed an automatic geneation of concuent execution paths to cove a paticula use-define fo concuent pogams. In the extended definition of use-define fo concuent pogams, a use statement includes the usage of a shaed vaiable, and the define statement includes the possibility that the value can be defined fom othe theads. We call this an extended use-define. Which thead actually defines the value in a paticula execution ould depend on the inteleaving. The use-define set can be obtained by analyzing the execution tace o souce code. Since the method poposed in this pape iteatively geneates diffeent inteleavings based on pevious execution taces, it is sufficient to use the use-define set obtained only fom the execution tace. The use-define set obtained by the static analysis of souce code may contain edundant elements. Infomation fom the souce code can be used as a supplement if execution taces (Advance online publication 19 August 2013)
IAENG Intenational Jounal of Compute Science, 403, IJCS_40_3_02 1 st Thead T1 1 lock a 2 hile(condition){ 3 ite x 4 unlock a 5 } Execution 1 Iteates once T1 1 lock a 2 hile( ) { 3 ite x 4 unlock a T2 20 lock a 21 ead x 22 unlock a 1 st 2 nd Thead T2 20 lock a 21 ead x 22 unlock a Execution 2 Iteates tice T1 1 lock a 2 hile( ) { 3 ite x 4 unlock a 2 hile( ) { 3 ite x 4 unlock a T2 20 lock a 21 ead x 22 unlock a 1 st 2 nd 3 d Execution 3 Iteates thee times T1 1 lock a 2 hile( ) { 3 ite x 4 unlock a 2 hile( ) { 3 ite x 4 unlock a 2 hile( ) { 3 ite x 4 unlock a T2 20 lock a 21 ead x 22 unlock a Same individual accessmanne Fig. 7. Example of set of access-mannes fo a loop. access ithout peviously acquiing any locks do not contain complete infomation fo obtaining the use-define set. In this pape, e assume that the execution tace contains enough infomation to obtain the use-define set consisting of tiplets of vaiable names, ead o ite opeations, and locations. Fig. 8 shos an example of a use-define set fo the pogam example in Fig. 3. To detect a conventional use-define, e identify the vaiable in a thead s execution tace and check if it foms a conventional use-define. To detect an extended use-define, e fist need to identify shaed vaiables fom the execution tace. A vaiable is shaed if it is accessed by moe than one thead. In the example of Fig. 8, e see that the vaiable x and y ae shaed vaiables because they ee accessed by moe than one thead. Fo each access to a shaed vaiable in a thead, e check if it foms an extended use-define ith anothe thead. In the example of Fig. 8, the ead opeation on shaed vaiable x in line 1 and the ite opeation on shaed vaiable x in line 10 fom an extended use-define. Thee ae seveal examples of use-define in Fig. 8, as follos Conventional use-define ud2 = (n, 2, 1), ud4 = (x, 12, 10) Extended use-define fo concuent pogams ud1 = (x, 1, 10), ud3 = (x, 1, 11), ud5 = (y, 7, 11) Since a ait-notify mechanism can change data flo, it might cause some infeasible use-defines. This situation could happen, fo example, hen thee is a ait command ithout the coesponding notify command. In this example, the use o define afte the ait command ill not be executed, so the use-define becomes infeasible. C. Yang, A.L. Soute, and L. L. Pollock [10] [34] descibe some complications that synchonization causes duing data flo analysis. Some infeasible use-defines might be included in a use-define set, but they ill not be executed and ill not be used fo gouping execution-vaiants. The infeasible use-define pais ill cause edundancy in the use-define set, but they ill not cause edundancy in test case geneation. Fo identifying data flo, e define a dependency elation beteen use-defines. A use-define ud2 depends on anothe use-define ud1, if the definition fo the vaiable in use-define ud2 is using the vaiable in the use-define ud1. It is basically a dependency elation. When thee can be only one assignment statement fo evey line of code, a use-define ud2 depends on anothe use-define ud1 hen the folloing condition is satisfied define_location of use-define ud2 = = use_location of use-define ud1 An example of a dependency elation beteen use-defines is shon in Fig. 8. Since the def_location of use-define ud1 is the same as the use_location of use-define ud2, use-define ud2 depends on use-define ud1. This means that thee is data flo fom the vaiable x to the vaiable n, because the definition of vaiable n in line 1 uses the vaiable x in line 10. In a simila ay, the use-define ud2 depends on the use-define ud3. We define BanchRelUD(b) as a set of use-defines on hich a conditional statement of a banch b could depend. It is basically a dependency elation. Algoithm 2 shos ho to find the membes of BanchRelUD(b) using the dependency elation of use-define. We also define BanchRelOP(b) as a set of ead and ite opeations fom membes of BanchRelUD(b). They ae ead and ite opeations on shaed vaiables fom the use-define that has a data flo elation ith the vaiables in the conditional statement of a banch b. Membes of BanchRelOP(b) ae opeations in theads hich ae defined as tiples locationopeationopeand as defined in the Model fo Concuent Pogam Execution Taces subsection. Algoithm 2. Finding a set of opeations that is affecting banch outcomes. Input - SetUD set of use-defines fom a concuent pogam execution tace. - A banch b. Data Flo Relation ith use-define (Advance online publication 19 August 2013)