SideTrack: Generalizing Dynamic Atomicity Analysis
|
|
- Madlyn Lindsey
- 5 years ago
- Views:
Transcription
1 SideTrack: Generalizing Dynamic Atomicity Analysis Jaeheon Yi Caitlin Sadowski Computer Science Department University of California at Santa Cruz Santa Cruz, CA Cormac Flanagan ABSTRACT Atomicity is a key correctness specification for multithreaded programs. Prior dynamic atomicity analyses include precise tools, which report an error if and only if the observed trace is not serializable; and imprecise tools, which generalize from the observed trace to report errors that might occur on other traces, but which may also report false alarms. This paper presents SideTrack, a lightweight online dynamic analysis that generalizes from the observed trace without introducing the potential for false alarms. If SideTrack reports an error, then some feasible trace of the source program is not serializable. Experimental results show that this generalization ability increases the number of atomicity violations detected by SideTrack by 40%. Categories and Subject Descriptors D.2.4 [Software Engineering]: Software/Program Verification reliability; D.2.5 [Software Engineering]: Testing and Debugging testing tools; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Programs specification techniques; F.3.2 [Logics and Meanings of Programs]: Semantics of Programming Languages program analysis General Terms Languages, Algorithms, Verification Keywords Atomicity, serializability, dynamic analysis 1. INTRODUCTION Recent trends in microprocessor architectures have made concurrency a central strategy for scaling up the performance of software. Unfortunately, writing correct multithreaded programs has proven to be very difficult because reasoning about program correctness must be done at the level of thread interleavings and platform-specific memory models. As our society depends increasingly on large software systems, reliability of multithreaded programs is an increasingly important concern. A crucial issue to consider is what it means for a multithreaded program to be correct, and how to specify correctness. A general specification for multithreaded programs is atomicity, a strong non-interference property that is widely applicable amongst many different programs. Informally, a block of code is atomic if, for all executions of that code block, the effect of that execution can be considered in isolation from the rest of the running program. In the database literature this property is often called serializability [3]. Atomicity corresponds to a natural way of thinking about concurrency, where the problem of reasoning about interleavings between individual operations is reduced to reasoning about interleavings between much coarser atomic blocks. Inside an atomic block, simpler sequential reasoning may be applied to show correctness. While atomicity is related to the notion of race-freedom [23], these two correctness properties provide complementary guarantees. Race-freedom guarantees that the program behaves as if executed on a sequentially-consistent memory model [1], while atomicity guarantees that each atomic block behaves as if executed serially. In this paper, we focus on dynamically detecting atomicity violations in traditional multithreaded programs based on synchronization idioms such as locks, fork, join etc. Prior work on dynamic atomicity analysis includes both precise and imprecise tools. Precise dynamic atomicity analyzers, such as Velodrome and others [17, 11], never produce false alarms. Instead, they report an atomicity violation if and only if the observed trace is not serializable. In contrast, imprecise tools, such as Atomizer and others [13, 31, 34, 33], generalize from the observed trace to also report errors which may (or may not) occur on other possible traces. In practice, these imprecise tools may report false alarms, which are notoriously difficult to distinguish from real error reports. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PADTAD 09, July 19-20, 2009, Chicago, Illinois, USA. Copyright 2009 ACM /09/07...$ Sound trace generalization. This paper explores a third approach, which is to generalize from the observed trace without introducing the potential of false alarms. Even if the observed trace is serializable, our online analysis can still infer that the original program can generate other feasible traces that are not serializable.
2 To illustrate this idea, consider the trace in Figure 1, where Thread 1 contains an atomic block with two synchronized statements, Thread 2 contains a single synchronized statement, and where the vertical ordering of the statements of the two threads reflects their relative execution order. as shown in Figure 3 (a), (b), and (c), respectively. Prior precise tools such as Velodrome only detect in-errors; SideTrack introduces the additional ability to detect beforeerrors and after-errors 1. V Figure 1: Observed Serial Trace Clearly, this trace is serial and hence trivially serializable, and so a precise checker such as Velodrome would not detect any errors. A careful analysis of this trace, however, shows that the synchronized statement of Thread 2 could have been scheduled in between the two synchronized statements of Thread 1; the original source program that generated the trace of Figure 1 is also capable of generating the non-serializable trace shown in Figure 2. Figure 2: Feasible Non-Serializable Trace Technically, the synchronized block of Thread 2 could diverge in this alternate trace. Our analysis assumes that all synchronized blocks terminate, and that the program is free of race conditions. This latter assumption can be discharged by concurrently running an efficient precise race detector such as FastTrack [14] or Goldilocks [9]. We would like to catch the violation of Figure 2 without having to observe it directly. Whenever the same lock is acquired twice within a transaction, there is a vulnerable window between the two acquires where a culprit acquire by another thread could cause an atomicity violation. SideTrack. In this paper we introduce SideTrack, an online predictive atomicity analysis. By observing the serial trace of Figure 1, our dynamic analysis can detect that the source program contains an atomicity violation, even though that violation does not manifest itself in the current trace. Thus, our analysis generalizes from the observed trace to detect errors that are guaranteed to occur on another feasible trace. Furthermore, unlike prior imprecise tools, it performs this generalization without introducing false alarms. Our analysis detects three kinds of errors before-errors, in-errors, and after-errors depending on where the culprit acquire occurs in relation to the vulnerable window, (a) before-errors V (b) in-errors V (c) after-errors Figure 3: Three Kinds of Atomicity Violations Although the above examples are rather straightforward, in practice generalizing from the observed trace in a sound manner may be rather involved. To illustrate some of the issues, consider an alternate trace shown in Figure 4, where the second synchronized block of Thread 1 forks Thread 2. In this situation, the synchronized statement of Thread 2 cannot be scheduled between the two synchronized statements of Thread 1. Despite the similarities between Figures 1 and 4, the first trace reflects an atomicity error in the source program, whereas the second trace does not. SideTrack needs to perform a careful analysis of the happens-before relation of the observed trace to detect situations where certain synchronized blocks could have been scheduled before other synchronized blocks. SideTrack uses the standard technique of vector clocks to provide a compact and efficient representation of this happens-before relation. SideTrack tracks the relative timing of synchronization operations and flags an error if an operation by another thread is concurrent with one of the operations flanking a vulnerable window. 1 Some tools do generalize to other traces using a combination of online and offline analysis; please see the related work section for more details.
3 sync(m) { fork(2); Figure 4: Observed Serial Trace with Fork Empirical validation. On a range of standard multithreaded benchmarks, we show that generalizing from the observed trace significantly increases SideTrack s ability to detect atomicity violations, without introducing false alarms. In particular, SideTrack detected 27 in-errors, which would also be detected by prior precise tools such as Velodrome. However, Side- Track also predicted an additional 11 atomicity violations that did not occur on the observed trace, but which could occur on other feasible traces. Thus, the ability to soundly generalize from the observed trace increased the number of atomicity violations detected by SideTrack by 40%. Summary. This paper contains the following contributions: We show how serializable traces can still reveal atomicity violations in the original program. We present SideTrack, a lightweight on-line dynamic analysis tool that generalizes from the observed trace to predict atomicity violations that could occur on other feasible traces. SideTrack performs this generalization without introducing false alarms. We present experimental results showing that this predictive ability increases the number of atomicity violations detected by SideTrack by 40%. Our results also show that, despite performing on-line generalization, SideTrack offers performance competitive with other dynamic analyses. 2. MULTITHREADED PROGRAM TRACES We begin by formalizing the notion of multithreaded program traces, which serve as the input to our dynamic analysis. A program consists of a number of concurrently executing threads that manipulate variables x Var and locks m Lock. Each thread has a thread identifier t Tid. A trace α captures an execution of a multithreaded program by listing the sequence of operations performed by the various threads. The set of operations that a thread t can perform include: rd(t, x) and wr(t, x), which read and write from variable x; acq(t,m) and rel(t, m), which acquire and release a lock m; begin(t, l) and end(t, l), which demarcate an atomic block labelled l; fork(t, u), which forks a new thread u; and join(t, u), which blocks until thread u terminates. We are concerned with the traces produced from an actual run of a source program. These traces will be well-formed; they fulfill expected constraints when forking, joining, acquiring and releasing. For example, every release operation has a corresponding acquire operation by the same thread earlier in the trace, and no operations by thread u occur in a trace prior to the forking of thread u. Two operations in a trace conflict if they satisfy one of the following conditions: Lock conflict: they acquire or release the same lock. Fork-join conflict: one operation is either fork(t, u) or join(t, u) and the other operation is by thread u. Program order conflict: they are performed by the same thread. The happens-before relation < α on a trace α is the smallest transitively-closed relation on operations in α such that if operation a occurs before b in α and a conflicts with b, then a happens-before b and b happens-after a. Two traces are equivalent if one can be obtained from the other by repeatedly swapping adjacent non-conflicting operations. Equivalent traces yield the same happens-before relation, and exhibit equivalent behavior. A transaction in a trace α is the sequence of operations executed by a thread t starting with a begin(t,l) operation and containing all t operations up to and including a matching end(t, l) operation. To simplify some aspects of the formal presentation, we assume begin(t, l) and end(t, l) operations are appropriately matched and are not nested (although our implementation does support nested atomic specifications). In a serial trace, all operations from each transaction are grouped together and not interleaved with the operations of any other transaction. A trace is serializable if it is equivalent to a serial trace. If two operations in a trace have a fork-join or program order conflict, then we say they have an enables conflict. The enables relation α is the smallest transitively-closed relation on operations in α such that if operation a occurs before b in α and a has an enables conflict with b, then a enables b. A lock operation a in α is concurrent with a later lock operation b by a different thread unless there exists an operation c between a and b such that a < α c and c α b. This is a tricky definition and is important for the later discussion, so it is worth developing the intuition behind it. In essence, in a hypothetical alternate trace where b occurs before a, c would also need to occur before a. However, once the happens-before edge between c and a is reversed, the thread which executed c may take an alternate path of execution. Since c enables b, this means that b may not occur if c occurs earlier. In any good definition of concurrent, two concurrent operations may execute in either order. Therefore, to identify concurrent operations we need to ensure that a dependency does not exist between them. The happens-before relation identifies dependencies but is too restrictive; every pair of lock operations on the same lock are related by happensbefore. The enables relation is too weak; the lock operations
4 on m by different threads in Figure 5(a) are not related by enables, but it may not be possible to execute them in a different order (Figure 5(b)). Vector clocks. SideTrack uses vector clocks [22] to identify concurrent acquire operations within a trace. Vector clocks compactly represent the happens-before relation. A vector clock maps thread identifiers to integer clocks: VC def = Tid Nat If vc is the vector clock for an acquire operation in a trace, then vc(t) identifies the operations of thread t that happenbefore that acquire. Vector clocks are partially-ordered ( ) in a point-wise manner, with an associated join operation ( ) and minimal element (c 0). In addition, the helper function inc t increments the t-component of a vector clock: vc 1 vc 2 iff t. vc 1(t) vc 2(t) vc 1 vc 2 = λt. max(vc 1(t),vc 2(t)) c 0 = λt. 0 inc t(vc) = λu. if u = t then vc(u) + 1 else vc(u) 3. ANALYSIS We refer to the actual trace perceived by our analysis tool as the observed trace. In addition to the observed trace, many other feasible traces exist for a given program. It is not generally possible to predict all feasible traces for a program without additional static information; for example, the observed trace may not have complete code coverage for the source program. Nevertheless, our analysis detects situations where a feasible but not observed atomicity violation can be predicted dynamically. Whenever the same lock is acquired twice within a transaction, there is a vulnerable window between the two acquires where an acquire by another thread could cause an atomicity violation. Our analysis keeps track of these vulnerable windows, and flags an error if it detects that a feasible trace exists which exploits a vulnerable window to cause an atomicity violation. We refer to the external acquire which could occur in the vulnerable window as a culprit acquire. Note that when predicting feasible traces dynamically, it is not possible to predict the entire trace. For example, we can predict that a lock acquire could have occurred between the two previous acquires, but the trace after that point may not be predictable based on the information obtained from the first trace. Instead, our analysis can only predict that there exists some alternate trace with an atomicity violation, where the alternate trace shares a prefix with the observed trace and executes certain synchronized blocks in a certain order. Because of these inherent limitations in our ability to generalize from the observed trace, some traces which appear at first glance to have a predictable atomicity violation turn out to be more complicated upon closer inspection. For example, consider the trace in Figure 5(a), where it appears the synchronized block of Thread 2 could execute inside the vulnerable window of Thread 1. However, if the read of b by Thread 2 executes before the write to b by Thread 1, we can no longer predict the subsequent execution of Thread 2, and in particular cannot guarantee that Thread 2 will still synchronize on the lock m (Figure 5(b)). The notion of concurrency defined in Section 2 captures these constraints. V write b; read b; write y;... (a) Thread 2 synchronizes on lock m. V write b; read b; //no idea (b) Thread 2 may not synchronize on lock m, due to an alternate control flow. Figure 5: A non-vulnerable atomic block due to the happens-before edge on the lock n, which protects the variable b. As stated in the introduction, our analysis detects three different kinds of errors (before-errors, after-errors, and in-errors), depending on where the culprit acquire occurs in relation to the vulnerable window. In a before-error, the culprit acquire occurred before the vulnerable window, as illustrated in Figure 3(a). To detect before-errors, the analysis records the vector clock of the most recent acquire of each lock. When a lock is first acquired in an atomic block, the analysis checks if that acquire is concurrent with the previous acquire of that lock, via a vector clock comparison. If the two acquires are concurrent, then that lock is recorded as being potentially interfering in that atomic block; if the atomic block subsequently re-acquires that lock, then a before-error atomicity violation is reported. Note that it is not enough to keep track of the most recent release of each lock. It is possible for a lock release by Thread 1 to be concurrent with an acquire of the same lock...
5 by Thread 2, while the corresponding acquire by Thread 1 enables the acquire by Thread 2. In the most extreme case, Thread 1 could fork Thread 2 while holding the the lock. In an in-error, the culprit acquire occurs in the vulnerable window, as in Figure 3(b). Other dynamic atomicity analysis tools that do not generalize to additional traces typically catch in-errors; an in-error represents an actual atomicity violation in the observed trace. We catch in-errors inside the vulnerable window, when the program is about to execute the second acquire within the transaction. There is an atomicity violation if a thread is about to acquire the same lock twice within a transaction and discovers the last release of that lock is concurrent with the acquire about to happen 2. In an after-error, the culprit acquire occurs after the vulnerable window, as in Figure 3(c). We catch aftererrors when the program is about to execute the culprit acquire. We keep track of the most recent vulnerable window for every lock. If the vector clock for an acquire by a different thread is not later than the vulnerable window, than that thread could have executed the acquire in the vulnerable window. Analysis formalization. Based on these ideas, we now formally define our atomicity analysis as an online algorithm based on an analysis state σ = (C, V, A, R, H,I) where: C : Tid VC records the vector clock of the current operation by each thread; V : Lock VC records the vector clock of the most recent vulnerable window for each lock; A : Lock VC records the vector clock of the last acquire of each lock; R : Lock VC records the vector clock of the last release of each lock; H : Tid 2 LOCKS {NotInX records the set of locks held within the current transaction by each thread, or NotInX if that thread is not currently within a transaction; and I : Tid 2 LOCKS records the set of potentially interfering locks for each thread. In the initial analysis state, all vector clocks are initialized to c 0, except each C t starts at inc t(c 0) to reflect that the first steps by different threads are not ordered. σ 0 = (λt.inc t(c 0), λm. c 0, λm. c 0, λm. c 0, λt. NotInX, λt. ) Figure 6 shows how the analysis state is updated for each operation a of the target program. The first rule [enter] for begin(t,l) records that thread t is in a new transaction by switching H t away from NotInX 2 Concurrent operations are by different threads, so this would mean that another thread acquired the lock. to, and resets the set of interfering locks. The complementary rule for end(t, l) records that t is no longer in a transaction. Here, H is a function, H t abbreviates the function application H(t), and H[t := V ] denotes the function that is identical to H except that it maps t to V. Changes to the instrumentation state are expressed as functional updates for clarity in the analysis rules, but are implemented as in-place updates in our implementation. Read and write operations do not affect the analysis state. If required, race conditions can be detected by running Side- Track concurrently with a race detector such as Fast- Track [14]. We do not yet consider reads and writes of volatile variables which create nonblocking synchronization, although we believe we can adapt our analysis to handle these constructs. We update vector clocks for fork and join operations to reflect the structure of the enables relation. The rule [fork] for fork(t, u) performs one clock tick for thread t and sets the vector clock associated with u to be greater than previous operations by thread t. The rule [join] records that the last operation of the joined thread enables the join operation. The vector clock for the joined thread is incremented to preserve the invariant that the current vector clocks for each running thread are incomparable. There are three analysis rules associated with an acq(t, m) operation. All three rules share three common antecedents which: 1. update the vector clock for t to reflect that the current time for t is later than the previous release of m; C = C[t := C t R m] 2. update the last acquire for m appropriately; A = A[m := C t] 3. and report an after-error if the vulnerable window for m is not before the current clock for t: if V m C t then after-error The rule [outside acquire] applies to acquires that are not within a transaction, and simply performs the above three actions. The rule [first acquire] applies the first time a thread acquires a lock within a transaction. We add m to the set of locks H t acquired within that transaction, and check if the previous acquire of m was concurrent. If so, we add m to the set I t of potentially interfering locks for that thread. The rule [second acquire] applies the second time a thread acquires a lock within a transaction. We record the new vulnerable window for m in V m. We flag a before-error if there is a previous interfering lock which could have executed after the first acquire by t. We flag an in-error if the previous release of m is not before the current clock for t. All previous operations by t, including the first acquire of m by t, are before the current clock of t. Therefore, if R m C t, then another thread released (and previously acquired) m between the two acquires by t. The rule [release] for rel(t,m) updates the vector clock associated with the latest release for m. We also perform one clock tick for thread t.
6 Figure 6: SideTrack Atomicity Violation Detection Algorithm [enter] H = H[t := ] I = I[t := ] (C, V, A,R, H,I) begin(t,l) (C, V, A, R,H, I ) [read] (C, V, A,R, H,I) rd(t,x,v) (C, V, A, R, H,I) [fork] C = C[t := inc t(c t), u := C t C u] (C, V, A,R, H,I) fork(t,u) (C, V, A, R, H,I) [first acquire] H t NotInX m / H t if V m C t then after-error C = C[t := C t R m] A = A[m := C t] H = H[t := H t {m] I = (if A m C t then I else I[t := I t {m]) (C, V, A, R, H,I) acq(t,m) (C, V, A, R,H, I ) [outside acquire] H t = NotInX if V m C t then after-error C = C[t := C t R m] A = A[m := C t] (C, V, A,R, H,I) acq(t,m) (C, V, A, R,H, I) [exit] H = H[t := NotInX] (C, V, A, R,H, I) end(t,l) (C, V, A, R, H, I) [write] (C, V, A, R,H, I) wr(t,x,v) (C, V, A, R, H,I) [join] C = C[t := C t C u, u := inc u(c u)] (C, V, A, R,H, I) join(t,u) (C, V, A,R, H, I) [second acquire] m H t if m I t then before-error if R m C t then in-error if V m C t then after-error C = C[t := C t R m] V = V [m := V m C t] A = A[m := C t] (C, V, A, R,H, I) acq(t,m) (C, V, A, R, H,I) [release] C = C[t := inc t(c t)] R = R[m := C t] (C, V, A, R,H, I) rel(t,m) (C, V, A,R, H, I) Examples. Figure 7 shows how vector clocks are updated on a sample trace fragment involving an after-error. The I and A parts of the analysis state play no part in discovery of after-errors, so they are omitted from the figure for simplicity. After the first release by thread 0, C 0 is incremented from <5,0...> to <6,0,...> and R m is set to <5,0...>. When m is acquired a second time by thread 0, V m is set to the current time for thread 0 (<6,0,...>). At the second release by thread 0, C 0 is incremented again from <6,0...> to <7,0,... > and R m is updated to <6,0...>. When thread 1 goes to acquire m, an after-error is reported because V m C 1. Once the after-error is reported, C 1 is joined with the time of the last release (R m). The example in Figure 8 illustrates that after-errors are more amenable to detection than before-errors. Side- Track finds the after-error in the bottom trace because the acquires of m by the two threads are concurrent. In the top trace, the synchronization on n means that the acquires of m are not concurrent: the acquire of n by thread 2 (and, by transitivity, the acquire of m by thread 2) happensbefore the acquire of n by thread 1 and the acquire of n by thread 1 enables the acquires of m by thread 1. Therefore, a before-error is not detected in this case. 4. IMPLEMENTATION We have developed a prototype implementation, called SideTrack, of our dynamic atomicity analysis. SideTrack is a component of RoadRunner, a framework designed for developing dynamic analyses for multithreaded programs. RoadRunner supports chaining of tools, so that multiple analyses can be run concurrently. RoadRunner instruments the target bytecode of a program during load time. The instrumentation code generates a stream of events for lock acquires and releases, field and array accesses, method entries and exits, etc 3. RoadRunner tools, such as Side- Track, process this event stream as it is generated. Road- Runner enables analysis tools to attach instrumentation state to each thread, lock object, and data memory location used by the target program. Tool-specific event handlers update the instrumentation state for each operation in the observed trace and report errors when appropriate. Analysis implementation. By default, SideTrack checks for the specification that all methods are atomic. This lifts transactions to the method call level, and nested transactions represent nested method calls. Each of the analysis rules in Figure 6 consists of one or more antecedents and a single consequent. Three rules are necessary to describe the event handler for acquires. When implementing these rules, it is useful to break down the antecedents into conditionals, checks, and updates. Conditionals indicate where the code must branch in an event handler. 3 Re-entrant lock acquires and releases are redundant and are filtered out by RoadRunner.
7 C 0 H 0 C 1 H 1 V m R m 5,0, ,3, ,0,... 0,0,... acq(0,m) 5,0,... m.. rel(0,m) 6,0,... m.. V acq(0,m) 6,0,... m.. rel(0,m) 7,0,... m.. 0,3, ,3, ,3, ,3,..... acq(1,m) V m C 1 : after-error 0,0,... 0,0,... 6,0,... 6,0,... 0,0,... 5,0,... 5,0,... 6,0,... 7,0,... m.. 6,3,... m.. 6,0,... 6,0,... Figure 7: Illustration of the Analysis State When Discovering an after-error Checks indicate when the analysis should flag an error. Updates describe how the next analysis state is obtained. For example, the rule [first acquire] has two branches with negated counterparts in different rules: H t NotInX and m / H t, and one internal branch: if A m C t... The crucial check is V m C t. If this check is violated, Side- Track issues an after-error warning. Blame assignment. Our analysis as presented is relatively straightforward to implement, and successfully flags feasible atomicity violations. Accurate blame assignment requires significant extra work, especially since before-error and after-error atomicity violations do not manifest in the observed trace. In the presence of nested transactions, it is not sufficient to report the (inner) transaction where the second acquire of a vulnerable window occurs. To illustrate this difficulty, consider the program shown in Figure 9, where we assume that all methods should be atomic. While methods c and d are atomic, a and b potentially have atomicity violations. When we encounter the second acquire in the vulnerable window inside of b, the call stack may look like a:b:c:d. However this call stack is not precise enough to tell us which method is non-atomic. In fact, we need the call stack for the first acquire of m inside the vulnerable window as well: a:b:d. We need to identify the common prefix in the two stacks, and report all methods in this prefix as non-atomic (here, a and b). We store a call stack for the first and second acquires for the last vulnerable window in the instrumentation state associated with each lock, and call stacks for all locks acquired in the current transaction in the instrumentation state associated with each thread. With a suitable immutable linked-list representation, recording such a stack is a constant-time operation. nc(m) {... sync(m) {... Figure 8: SideTrack flags the trace on the bottom with an atomicity violation, but not the trace on the top. Tool complementation. We can combine SideTrack with Velodrome [17], a sound and complete dynamic atomicity analysis, to increase coverage. Velodrome finds more atomicity violations from a particular trace than SideTrack, since Velodrome also looks for atomicity violations involving accesses to shared variables as well as locks. However, SideTrack finds feasible errors that Velodrome misses, since the latter does not generalize its analysis to other feasible traces. Thus the two tools are compatible and complementary. Since RoadRunner supports tool composition, it is straightforward to run these two together. Test case generation. SideTrack was tested using Tiddle [26], a trace description language and compiler that translates trace fragments into deterministic multithreaded Java programs. We have found that it is substantially easier to develop a custom test suite tailored for a particular dynamic analysis using Tiddle, as describing good and bad trace scenarios is simply a matter of jotting down the appropriate trace fragments. 5. EVALUATION We present encouraging experimental results for Side- Track. We ran these experiments on a machine with 3 GB memory, 2.16 GHz dual-core CPU, running Mac OS X , and with Java HotSpot 64-Bit Server JVM Our benchmark set includes: elevator, a real-time discrete event simulator [30]; colt, a library for high performance scientific computing [5]; jbb, the spec jbb2000 simulator for business middleware [28]; hedc, a warehouse webcrawler for astrophysics data [30]; barrier, a barrier synchronization performance benchmark [19]; philo, a dining philosophers application [9]; tsp, a solver for the traveling salesman problem [30]; and sync, a synchronization performance benchmark [19]. Benchmarks from Java Grande [19]
8 func a() { b(); func b() { d(); c(); func c() { d(); func d() { Potentially not atomic Atomic Figure 9: Program Example Where Precise Blame Assignment Is Necessary Table 1: Atomicity Errors Found by SideTrack. Types of Errors Methods with Errors before-errors in-errors after-errors Predicted befores Predicted afters Predicted Total Programs elevator colt jbb hedc barrier philo tsp sync Total were configured to use 4 threads and the base data set. This set totals over 200K lines of code. Excluding the Java standard libraries, all classes loaded by benchmark programs were instrumented. To check for atomicity violations, we assumed that all methods should be atomic. In practice this assumption works fairly well; previous experiments have validated that atomicity is a fundamental design principle for concurrency [13, 21]. For each benchmark, Table 1 reports both the total number of methods with atomicity violations (Column 2) as well as the error count for each type of atomicity violation (Columns 3-5). Note that there is significant overlap between the methods reported by each kind of violation. To further clarify the benefit of SideTrack s predictive analysis, Column 6 reports the number of before-errors that are not in-errors (and so not detected by earlier precise tools), and Column 7 reports on after-errors that are not in-errors. Finally, the last column reports on errors that are either before-errors or after-errors, but not in-errors, and so most clearly summarizes the improvement achieved via predictive analysis. SideTrack s predic- Table 2: Benchmark Performance Results Num Threads LOC Base Runtime (Seconds) Slowdown (Empty) Slowdown (SideTrack) Programs colt , barrier tsp sync crypt 7 1, moldyn 4 1, forkjoin lufact 4 1, montecarlo 4 3, raytracer 4 1, series sor 4 1, tive ability catches an additional 11 errors, in addition to the 27 in-errors: an improvement of roughly 40%. Interestingly, all 11 of these additional violations were found by the after analysis, which suggests that the after analysis generalizes better than the before analysis. To confirm that the predicted errors are not false positives, we investigated the error messages in the Predicted Total column by inspecting the program source code. We found that it was easy to pinpoint the errors with the blame assignment information. All were judged to be vulnerable to atomicity violations. However, some of these violations may be benign. Table 2 reports on the performance of our analysis. For each of the compute-bound benchmarks, we report on the running time of that benchmark (without any instrumentation), and on the slowdown incurred by RoadRunner when running with the Empty tool (which just measures the instrumentation overhead but performs no dynamic analysis); and the slowdown when run with SideTrack. We also measured performance for all other benchmarks in the Java Grande suite; SideTrack reported no errors (of any of the three types) for these additional benchmarks. The average slowdown for SideTrack was 8.1x, as compared with a slowdown for the Empty tool of 6.8x. There are a couple outliers. The forkjoin benchmark taxes our instrumentation framework by forking and joining almost 200 threads, each of which has an associated instrumentation state. Additionally, the running time of this benchmark is so short that other effects (like printing) may dominate the slowdown. Without forkjoin, the slowdown for SideTrack is 4.5x and the slowdown for the Empty tool is 3.3x. The 13.9x slowdown for raytracer is a result of the large number of small method calls in this benchmark, each of which must be recorded for blame assignment. The results show that SideTrack provides a significant improvement in performance of prior dynamic atomicity analyses, such as SingleTrack [25] (10.4x), Velodrome [17] (10.3x), and Atomizer [13]. This performance improvement is largely because SideTrack does not analyze memory reads and writes, and instead assumes that the target
9 program is race-free and any inter-thread communication is mediated via synchronization idioms such as locks. If necessary, this race-free assumption can be verified by concurrently running an efficient race detector such as Fast- Track [14], which would incur an additional performance overhead of 10x. We believe using separate analyses to verify race-freedom and atomicity offers benefits both in terms of performance and modularity of the analysis code. 6. RELATED WORK Atomicity violation detection tools. A variety of tools have been developed to detect atomicity violations, both statically and dynamically. Static analyses for verifying atomicity include type systems [18, 15, 27, 16, 32] as well as techniques that look for cycles in the happensbefore graph [10]. Compared to dynamic techniques, static systems provide stronger soundness guarantees but typically involve trade-offs between precision and scalability. Dynamic techniques analyze a specific executed trace at runtime. Artho et al. [2] have developed a dynamic analysis tool to identify one class of higher-level races using the notion of view consistency. Many dynamic techniques for detecting atomicity violations exist in the literature; we will expand on some of them here. The Atomizer [13] uses Lipton s theory of reduction [20] to check serializability, similar to the reduction-based algorithms described in [31, 34]. Atomizer looks for irreducible patterns in the trace and may find some errors that do not actually manifest in the observed trace. However, Atomizer may also report false positives, due to limitations in how Atomizer reasons about different synchronization idioms. In contrast, Velodrome [17] reports an error if and only if the observed trace is not serializable. Velodrome uses transactional happensbefore graphs to detect cycles, which correspond directly to an atomicity violation. Farzan and Madhusudan [11] provide space complexity bounds for a similar analysis. Predictive approaches. There have been a number of recent papers about predicting atomicity violations from an observed trace; note that none of these approaches are completely online. However, some of these tools offer increased coverage over SideTrack by using additional static information. HAVE [7] injects static method summaries into a dynamic context and speculates on unexecuted control flow branches to predict atomicity violations. This speculative technique may lead to false positives, but experimental results indicate that such messages are very rare. The kinds of predictions made by HAVE are different from those made by Side- Track, since HAVE bases its predictions on unobservedyet-feasible operations, while SideTrack uses the observed trace to infer a different-but-feasible scheduling. JPredictor [6] performs offline causality slicing on an observed trace to remove irrelevant events, then generates sound permutations of events to predict atomicity violations. Atomicity violations are detected by matching against 11 known violation patterns [29]. The hybrid techniques of HAVE and JPredictor make use of static control- and data-flow information and thus are complementary to our purely dynamic prediction technique. Wang and Stoller have developed a block-based algorithm [34] and commit-node algorithms that address both conflictatomicity (referred to as atomicity in this paper) and viewatomicity [33]. They monitor execution traces at runtime, and analyze those traces offline. By design, these algorithms report potential serializability violations that do not occur on the observed trace but which might occur on other traces. Although these algorithms potentially report false positives, this problem does not seem to arise in practice. Farzan and Madhusudan [12] predict runs from program models based on profiles and check serializability of the predicted runs. They develop time bounds and algorithms for straight-line, regular, and recursive programs with and without synchronization. Implementing prediction tools for atomicity violations based on their theoretical results remains future work. Scheduling atomicity violations. Sen and Park [24] have developed a tool called Atom- Fuzzer which attempts to schedule atomicity violations. They target the same pattern we do: one thread acquires the same lock twice within a transaction. They use the heuristic that every synchronized block should be atomic, instead of every method. When a thread is about to acquire the same lock a second time, AtomFuzzer pauses the thread (with probability 0.5), and tries to schedule another thread (which may cause an atomicity violation) first. If all threads are paused, one thread is chosen to continue. AtomFuzzer may miss some errors which we are able to catch, because it is not always possible (or desirable) to pause every thread as long as necessary at a vulnerable point. However, since AtomFuzzer actually produces an atomicity violation, the user is able to see what sorts of problems (e.g. exceptions) are caused by that violation. Additionally, AtomFuzzer may find errors that we are unable to report, by shaping a particular execution trace through scheduling. For example, AtomFuzzer may be able to drive execution to produce an atomicity violation for the trace in Figure 5, whereas we cannot discover if such a trace is feasible. These two approaches are complementary; scheduling (also see [8]) can be used to generate more atomicity violations for a particular trace while an analysis like SideTrack predicts other feasible violations. 7. FUTURE WORK Several issues remain for future work. We are currently developing formal proofs of our intended correctness property, namely that the analysis is complete and reports no false alarms on data-race-free programs. We are also extending our analysis to handle accesses to volatile variables and other synchronization idioms, such as barriers, wait-notify, etc. We would also like to extend this general approach for trace generalization to other specification idioms, such as race freedom and deterministic parallelism [25, 4]. 8. REFERENCES [1] S. V. Adve and K. Gharachorloo. Shared memory consistency models: A tutorial. IEEE Computer, 29(12):66 76, [2] C. Artho, K. Havelund, and A. Biere. High-level data races. In International Workshop on Verification and Validation of Enterprise Information Systems, 2003.
10 [3] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, [4] R. L. Bocchino, Jr., V. S. Adve, D. Dig, S. Adve, S. Heumann, R. Komuravelli, J. Overbey, P. Simmons, H. Sung, and M. Vakilian. A type and effect system for Deterministic Parallel Java. Technical Report UIUCDCS-R , Department of Computer Science, University of Illinois at Urbana-Champaign, [5] CERN. Colt Available from hoschek/colt/, [6] F. Chen, T. F. Şerbănuţă, and G. Roşu. jpredictor: a predictive runtime analysis tool for Java. In International Conference on Software Engineering, ACM, [7] Q. Chen, L. Wang, Z. Yang, and S. D. Stoller. HAVE: Integrated dynamic and static analysis for atomicity violations. In International Conference on Fundamental Approaches to Software Engineering (FASE), [8] O. Edelstein, E. Farchi, E. Goldin, Y. Nir, G. Ratsaby, and S. Ur. Framework for testing multi-threaded java programs. In Concurrency and Computation: Practice and Experience, volume 15, [9] T. Elmas, S. Qadeer, and S. Tasiran. Goldilocks: a race and transaction-aware Java runtime. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), , [10] A. Farzan and P. Madhusudan. Causal atomicity. In Computer Aided Verification (CAV), , [11] A. Farzan and P. Madhusudan. Monitoring atomicity in concurrent programs. In Computer Aided Verification (CAV), 52 65, [12] A. Farzan and P. Madhusudan. The complexity of predicting atomicity violations. In Tools and Algorithms for the Construction and Analysis of Systems (TACAS), [13] C. Flanagan and S. N. Freund. Atomizer: A dynamic atomicity checker for multithreaded programs. In ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (POPL), , [14] C. Flanagan and S. N. Freund. FastTrack: Efficient and precise dynamic race detection. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), To appear. [15] C. Flanagan, S. N. Freund, M. Lifshin, and S. Qadeer. Types for atomicity: Static checking and inference for Java. Transactions on Programming Languages and Systems, 30(4):1 53, [16] C. Flanagan, S. N. Freund, and S. Qadeer. Exploiting purity for atomicity. IEEE Transactions on Software Engineering, 31(4): , [17] C. Flanagan, S. N. Freund, and J. Yi. Velodrome: A sound and complete dynamic atomicity checker for multithreaded programs. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), [18] C. Flanagan and S. Qadeer. A type and effect system for atomicity. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), , [19] Java Grande Forum. Java Grande benchmark suite [20] R. J. Lipton. Reduction: A method of proving properties of parallel programs. Communications of the ACM, 18(12): , [21] S. Lu, S. Park, E. Seo, and Y. Zhou. Learning from mistakes: a comprehensive study on real world concurrency bug characteristics. SIGPLAN Notices, [22] F. Mattern. Virtual time and global states of distributed systems. In International Workshop on Parallel and Distributed Algorithms [23] R. H. B. Netzer and B. P. Miller. What are race conditions? Some issues and formalizations. ACM Letters on Programming Languages and Systems (LOPLAS), 1:74 88, [24] C.-S. Park and K. Sen. Randomized active atomicity violation detection in concurrent programs. In ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE), ACM, [25] C. Sadowski, S. N. Freund, and C. Flanagan. SingleTrack: A dynamic determinism checker for multithreaded programs. In European Symposium on Programming (ESOP), [26] C. Sadowski and J. Yi. Tiddle: A trace description language for generating concurrent benchmarks to test dynamic analyses. In International Workshop on Dynamic Analysis (WODA), To appear. [27] A. Sasturkar, R. Agarwal, L. Wang, and S. D. Stoller. Automated type-based analysis of data races and atomicity. In ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP), 83 94, [28] SPEC. Standard Performance Evaluation Corporation JBB2000 Benchmark [29] M. Vaziri, F. Tip, and J. Dolby. Associating synchronization constraints with data in an object-oriented language. In ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (POPL), , [30] C. von Praun and T. Gross. Static conflict analysis for multi-threaded object-oriented programs. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), , [31] L. Wang and S. D. Stoller. Runtime analysis for atomicity. In International Workshop on Runtime Verification (RV), [32] L. Wang and S. D. Stoller. Static analysis of atomicity for programs with non-blocking synchronization. In ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP), 61 71, [33] L. Wang and S. D. Stoller. Accurate and efficient runtime detection of atomicity errors in concurrent programs. In ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP), , [34] L. Wang and S. D. Stoller. Runtime analysis of atomicity for multithreaded programs. IEEE Transactions on Software Engineering, 32:93 110, Feb
FastTrack: Efficient and Precise Dynamic Race Detection (+ identifying destructive races)
FastTrack: Efficient and Precise Dynamic Race Detection (+ identifying destructive races) Cormac Flanagan UC Santa Cruz Stephen Freund Williams College Multithreading and Multicore! Multithreaded programming
CalFuzzer: An Extensible Active Testing Framework for Concurrent Programs Pallavi Joshi 1, Mayur Naik 2, Chang-Seo Park 1, and Koushik Sen 1
CalFuzzer: An Extensible Active Testing Framework for Concurrent Programs Pallavi Joshi 1, Mayur Naik 2, Chang-Seo Park 1, and Koushik Sen 1 1 University of California, Berkeley, USA {pallavi,parkcs,ksen}@eecs.berkeley.edu
FastTrack: Efficient and Precise Dynamic Race Detection By Cormac Flanagan and Stephen N. Freund
FastTrack: Efficient and Precise Dynamic Race Detection By Cormac Flanagan and Stephen N. Freund doi:10.1145/1839676.1839699 Abstract Multithreaded programs are notoriously prone to race conditions. Prior
Atomicity for Reliable Concurrent Software. Race Conditions. Motivations for Atomicity. Race Conditions. Race Conditions. 1. Beyond Race Conditions
Towards Reliable Multithreaded Software Atomicity for Reliable Concurrent Software Cormac Flanagan UC Santa Cruz Joint work with Stephen Freund Shaz Qadeer Microsoft Research 1 Multithreaded software increasingly
Cooperative Reasoning for Preemptive Execution
Cooperative Reasoning for Preemptive Execution Jaeheon Yi Caitlin Sadowski Cormac Flanagan Computer Science Department University of California at Santa Cruz Santa Cruz, CA 95064 {jaeheon,supertri,cormac@cs.ucsc.edu
Types for Precise Thread Interference
Types for Precise Thread Interference Jaeheon Yi, Tim Disney, Cormac Flanagan UC Santa Cruz Stephen Freund Williams College October 23, 2011 2 Multiple Threads Single Thread is a non-atomic read-modify-write
Cooperative Concurrency for a Multicore World
Cooperative Concurrency for a Multicore World Stephen Freund Williams College Cormac Flanagan, Tim Disney, Caitlin Sadowski, Jaeheon Yi, UC Santa Cruz Controlling Thread Interference: #1 Manually x = 0;
Runtime Atomicity Analysis of Multi-threaded Programs
Runtime Atomicity Analysis of Multi-threaded Programs Focus is on the paper: Atomizer: A Dynamic Atomicity Checker for Multithreaded Programs by C. Flanagan and S. Freund presented by Sebastian Burckhardt
Adversarial Memory for Detecting Destructive Races
Adversarial Memory for Detecting Destructive Races Cormac Flanagan Computer Science Department University of California at Santa Cruz Santa Cruz, CA 95064 Stephen N. Freund Computer Science Department
Dynamic Monitoring Tool based on Vector Clocks for Multithread Programs
, pp.45-49 http://dx.doi.org/10.14257/astl.2014.76.12 Dynamic Monitoring Tool based on Vector Clocks for Multithread Programs Hyun-Ji Kim 1, Byoung-Kwi Lee 2, Ok-Kyoon Ha 3, and Yong-Kee Jun 1 1 Department
Tiddle: A Trace Description Language for Generating Concurrent Benchmarks to Test Dynamic Analyses
Tiddle: A Trace Description Language for Generating Concurrent Benchmarks to Test Dynamic Analyses Caitlin Sadowski supertri@cs.ucsc.edu Computer Science Department University of California at Santa Cruz
DoubleChecker: Efficient Sound and Precise Atomicity Checking
DoubleChecker: Efficient Sound and Precise Atomicity Checking Swarnendu Biswas, Jipeng Huang, Aritra Sengupta, and Michael D. Bond The Ohio State University PLDI 2014 Impact of Concurrency Bugs Impact
Atomicity. Experience with Calvin. Tools for Checking Atomicity. Tools for Checking Atomicity. Tools for Checking Atomicity
1 2 Atomicity The method inc() is atomic if concurrent ths do not interfere with its behavior Guarantees that for every execution acq(this) x t=i y i=t+1 z rel(this) acq(this) x y t=i i=t+1 z rel(this)
A taxonomy of race. D. P. Helmbold, C. E. McDowell. September 28, University of California, Santa Cruz. Santa Cruz, CA
A taxonomy of race conditions. D. P. Helmbold, C. E. McDowell UCSC-CRL-94-34 September 28, 1994 Board of Studies in Computer and Information Sciences University of California, Santa Cruz Santa Cruz, CA
C. Flanagan Dynamic Analysis for Atomicity 1
1 Atomicity The method inc() is atomic if concurrent threads do not interfere with its behavior Guarantees that for every execution acq(this) x t=i y i=t+1 z rel(this) acq(this) x y t=i i=t+1 z rel(this)
Automatically Classifying Benign and Harmful Data Races Using Replay Analysis
Automatically Classifying Benign and Harmful Data Races Using Replay Analysis Satish Narayanasamy, Zhenghao Wang, Jordan Tigani, Andrew Edwards, Brad Calder Microsoft University of California, San Diego
Program Partitioning - A Framework for Combining Static and Dynamic Analysis
Program Partitioning - A Framework for Combining Static and Dynamic Analysis Pankaj Jalote, Vipindeep V, Taranbir Singh, Prateek Jain Department of Computer Science and Engineering Indian Institute of
Randomized Active Atomicity Violation Detection in Concurrent Programs
Randomized Active Atomicity Violation Detection in Concurrent Programs Chang-Seo Park EECS Department, UC Berkeley, CA, USA. parkcs@cs.berkeley.edu Koushik Sen EECS Department, UC Berkeley, CA, USA. ksen@cs.berkeley.edu
NDSeq: Runtime Checking for Nondeterministic Sequential Specs of Parallel Correctness
EECS Electrical Engineering and Computer Sciences P A R A L L E L C O M P U T I N G L A B O R A T O R Y NDSeq: Runtime Checking for Nondeterministic Sequential Specs of Parallel Correctness Jacob Burnim,
Joint Entity Resolution
Joint Entity Resolution Steven Euijong Whang, Hector Garcia-Molina Computer Science Department, Stanford University 353 Serra Mall, Stanford, CA 94305, USA {swhang, hector}@cs.stanford.edu No Institute
jpredictor: A Predictive Runtime Analysis Tool for Java
jpredictor: A Predictive Runtime Analysis Tool for Java Feng Chen CS Department University of Illinois, Urbana fengchen@cs.uiuc.edu Traian Florin Şerbănuţă CS Department University of Illinois, Urbana
Development of Technique for Healing Data Races based on Software Transactional Memory
, pp.482-487 http://dx.doi.org/10.14257/astl.2016.139.96 Development of Technique for Healing Data Races based on Software Transactional Memory Eu-Teum Choi 1,, Kun Su Yoon 2, Ok-Kyoon Ha 3, Yong-Kee Jun
More BSOD Embarrassments. Moore s Law. Programming With Threads. Moore s Law is Over. Analysis of Concurrent Software. Types for Race Freedom
Moore s Law Analysis of Concurrent Software Types for Race Freedom Transistors per chip doubles every 18 months Cormac Flanagan UC Santa Cruz Stephen N. Freund Williams College Shaz Qadeer Microsoft Research
A Case for System Support for Concurrency Exceptions
A Case for System Support for Concurrency Exceptions Luis Ceze, Joseph Devietti, Brandon Lucia and Shaz Qadeer University of Washington {luisceze, devietti, blucia0a}@cs.washington.edu Microsoft Research
Part 3: Beyond Reduction
Lightweight Analyses For Reliable Concurrency Part 3: Beyond Reduction Stephen Freund Williams College joint work with Cormac Flanagan (UCSC), Shaz Qadeer (MSR) Busy Acquire Busy Acquire void busy_acquire()
NDSeq: Runtime Checking for Nondeterministic Sequential Specifications of Parallel Correctness
NDSeq: Runtime Checking for Nondeterministic Sequential Specifications of Parallel Correctness Jacob Burnim Tayfun Elmas George Necula Koushik Sen Department of Electrical Engineering and Computer Sciences,
Hybrid Static-Dynamic Analysis for Statically Bounded Region Serializability
Hybrid Static-Dynamic Analysis for Statically Bounded Region Serializability Aritra Sengupta, Swarnendu Biswas, Minjia Zhang, Michael D. Bond and Milind Kulkarni ASPLOS 2015, ISTANBUL, TURKEY Programming
Sound Thread Local Analysis for Lockset-Based Dynamic Data Race Detection
Wellesley College Wellesley College Digital Scholarship and Archive Honors Thesis Collection 2017 Sound Thread Local Analysis for Lockset-Based Dynamic Data Race Detection Samuila Mincheva sminchev@wellesley.edu
Hybrid Analysis for Partial Order Reduction of Programs with Arrays
Hybrid Analysis for Partial Order Reduction of Programs with Arrays Pavel Parízek Charles University in Prague, Faculty of Mathematics and Physics, Department of Distributed and Dependable Systems Abstract.
Predictive Analysis for Detecting Serializability Violations through Trace Segmentation
Predictive Analysis for Detecting Serializability Violations through Trace Segmentation Arnab Sinha, Sharad Malik Princeton University Chao Wang, Aarti Gupta NEC Laboratories America Abstract We address
7/6/2015. Motivation & examples Threads, shared memory, & synchronization. Imperative programs
Motivation & examples Threads, shared memory, & synchronization How do locks work? Data races (a lower level property) How do data race detectors work? Atomicity (a higher level property) Concurrency exceptions
the complexity of predicting atomicity violations
the complexity of predicting atomicity violations Azadeh Farzan Univ of Toronto P. Madhusudan Univ of Illinois at Urbana Champaign. Motivation: Interleaving explosion problem Testing is the main technique
Motivation & examples Threads, shared memory, & synchronization
1 Motivation & examples Threads, shared memory, & synchronization How do locks work? Data races (a lower level property) How do data race detectors work? Atomicity (a higher level property) Concurrency
HEAT: An Integrated Static and Dynamic Approach for Thread Escape Analysis
HEAT: An Integrated Static and Dynamic Approach for Thread Escape Analysis Qichang Chen and Liqiang Wang Department of Computer Science University of Wyoming {qchen2, wang@cs.uwyo.edu Zijiang Yang Department
RATCOP: Relational Analysis Tool for Concurrent Programs
RATCOP: Relational Analysis Tool for Concurrent Programs Suvam Mukherjee 1, Oded Padon 2, Sharon Shoham 2, Deepak D Souza 1, and Noam Rinetzky 2 1 Indian Institute of Science, India 2 Tel Aviv University,
Toward Efficient Strong Memory Model Support for the Java Platform via Hybrid Synchronization
Toward Efficient Strong Memory Model Support for the Java Platform via Hybrid Synchronization Aritra Sengupta, Man Cao, Michael D. Bond and Milind Kulkarni 1 PPPJ 2015, Melbourne, Florida, USA Programming
Dynamic Analysis. CS252r Fall 2015
Dynamic Analysis CS252r Fall 2015 Reading The Concept of Dynamic Analysis by Thomas Ball, FSE 1999 Efficient Path Profiling by Thomas Ball and James Larus, MICRO 1996 Adversarial Memory for Destructive
Computing Approximate Happens-Before Order with Static and Dynamic Analysis
Department of Distributed and Dependable Systems Technical report no. D3S-TR-2013-06 May 7, 2018 Computing Approximate Happens-Before Order with Static and Dynamic Analysis Pavel Parízek, Pavel Jančík
VyrdMC: Driving Runtime Refinement Checking with Model Checkers
Electronic Notes in Theoretical Computer Science 144 (2006) 41 56 www.elsevier.com/locate/entcs VyrdMC: Driving Runtime Refinement Checking with Model Checkers Tayfun Elmas 1 Serdar Tasiran 2 College of
Using Block-local Atomicity to Detect Stale-value Concurrency Errors
Using Block-local Atomicity to Detect Stale-value Concurrency Errors Cyrille Artho 1, Klaus Havelund 2, and Armin Biere 1 1 Computer Systems Institute, ETH Zürich, Switzerland 2 Kestrel Technology, NASA
A Serializability Violation Detector for Shared-Memory Server Programs
A Serializability Violation Detector for Shared-Memory Server Programs Min Xu Rastislav Bodík Mark Hill University of Wisconsin Madison University of California, Berkeley Serializability Violation Detector:
Java Memory Model. Jian Cao. Department of Electrical and Computer Engineering Rice University. Sep 22, 2016
Java Memory Model Jian Cao Department of Electrical and Computer Engineering Rice University Sep 22, 2016 Content Introduction Java synchronization mechanism Double-checked locking Out-of-Thin-Air violation
Hybrid Dynamic Data Race Detection
Hybrid Dynamic Data Race Detection Robert O Callahan Jong-Deok Choi IBM T.J. Watson Research Center ACM SIGPLAN 2003 Symposium on Principles and Practice of Parallel Programming (PPoPP 03) San Diego, CA,
A Causality-Based Runtime Check for (Rollback) Atomicity
A Causality-Based Runtime Check for (Rollback) Atomicity Serdar Tasiran Koc University Istanbul, Turkey Tayfun Elmas Koc University Istanbul, Turkey RV 2007 March 13, 2007 Outline This paper: Define rollback
The Java Memory Model
Jeremy Manson 1, William Pugh 1, and Sarita Adve 2 1 University of Maryland 2 University of Illinois at Urbana-Champaign Presented by John Fisher-Ogden November 22, 2005 Outline Introduction Sequential
11/19/2013. Imperative programs
if (flag) 1 2 From my perspective, parallelism is the biggest challenge since high level programming languages. It s the biggest thing in 50 years because industry is betting its future that parallel programming
Handout 9: Imperative Programs and State
06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative
Cover Page. The handle holds various files of this Leiden University dissertation
Cover Page The handle http://hdl.handle.net/1887/22891 holds various files of this Leiden University dissertation Author: Gouw, Stijn de Title: Combining monitoring with run-time assertion checking Issue
Semantic Atomicity for Multithreaded Programs!
P A R A L L E L C O M P U T I N G L A B O R A T O R Y Semantic Atomicity for Multithreaded Programs! Jacob Burnim, George Necula, Koushik Sen! Parallel Computing Laboratory! University of California, Berkeley!
F-Soft: Software Verification Platform
F-Soft: Software Verification Platform F. Ivančić, Z. Yang, M.K. Ganai, A. Gupta, I. Shlyakhter, and P. Ashar NEC Laboratories America, 4 Independence Way, Suite 200, Princeton, NJ 08540 fsoft@nec-labs.com
Optimized Run-Time Race Detection And Atomicity Checking Using Partial Discovered Types
Optimized Run-Time Race Detection And Atomicity Checking Using Partial Discovered Types Rahul Agarwal Amit Sasturkar Liqiang Wang Scott D. Stoller ABSTRACT Concurrent programs are notorious for containing
Slides by Y. Nir-Buchbinder, adapted by O. Agmon Ben-Yehuda 1/30
Application of Synchronization Coverage Arkady Bron, Eitan Farchi, Yonit Magid, Yarden Nir-Buchbinder, Shmuel Ur PPoPP 2005 Presented in the spring 2011 Seminar on Advanced Topics in Concurrent Programming
Garbage Collection (2) Advanced Operating Systems Lecture 9
Garbage Collection (2) Advanced Operating Systems Lecture 9 Lecture Outline Garbage collection Generational algorithms Incremental algorithms Real-time garbage collection Practical factors 2 Object Lifetimes
Java PathFinder JPF 2 Second Generation of Java Model Checker
Java PathFinder JPF 2 Second Generation of Java Model Checker Guenther Brand Mat. Nr. 9430535 27. 06. 2003 Abstract This essay is based on the papers Java PathFinder, Second Generation of Java Model Checker
Java-MOP: A Monitoring Oriented Programming Environment for Java
Java-MOP: A Monitoring Oriented Programming Environment for Java Feng Chen and Grigore Roşu Department of Computer Science, University of Illinois at Urbana - Champaign, USA {fengchen, grosu}@uiuc.edu
Concurrency. Glossary
Glossary atomic Executing as a single unit or block of computation. An atomic section of code is said to have transactional semantics. No intermediate state for the code unit is visible outside of the
Symbolic Execution, Dynamic Analysis
Symbolic Execution, Dynamic Analysis http://d3s.mff.cuni.cz Pavel Parízek CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics Symbolic execution Pavel Parízek Symbolic Execution, Dynamic Analysis
Compiler Techniques For Memory Consistency Models
Compiler Techniques For Memory Consistency Models Students: Xing Fang (Purdue), Jaejin Lee (Seoul National University), Kyungwoo Lee (Purdue), Zehra Sura (IBM T.J. Watson Research Center), David Wong (Intel
AtomChase: Directed Search Towards Atomicity Violations
AtomChase: Directed Search Towards Atomicity Violations Mahdi Eslamimehr, Mohsen Lesani Viewpoints Research Institute, 1025 Westwood Blvd 2nd flr, Los Angeles, CA 90024 t: (310) 208-0524 AtomChase: Directed
Process Management And Synchronization
Process Management And Synchronization In a single processor multiprogramming system the processor switches between the various jobs until to finish the execution of all jobs. These jobs will share the
Concurrent Objects and Linearizability
Chapter 3 Concurrent Objects and Linearizability 3.1 Specifying Objects An object in languages such as Java and C++ is a container for data. Each object provides a set of methods that are the only way
PACER: Proportional Detection of Data Races
PACER: Proportional Detection of Data Races Michael D. Bond Katherine E. Coons Kathryn S. McKinley Department of Computer Science, The University of Texas at Austin {mikebond,coonske,mckinley}@cs.utexas.edu
Evaluating Research on Software Design and Productivity
Evaluating Research on Software Design and Productivity William Pugh Univ. of Maryland pugh@cs.umd.edu October 31, 2001 Abstract A key barrier to achieving the necessary breakthroughs in software design
Summary: Open Questions:
Summary: The paper proposes an new parallelization technique, which provides dynamic runtime parallelization of loops from binary single-thread programs with minimal architectural change. The realization
Duet: Static Analysis for Unbounded Parallelism
Duet: Static Analysis for Unbounded Parallelism Azadeh Farzan and Zachary Kincaid University of Toronto Abstract. Duet is a static analysis tool for concurrent programs in which the number of executing
Scalable and Precise Dynamic Datarace Detection for Structured Parallelism
Scalable and Precise Dynamic Datarace Detection for Structured Parallelism Raghavan Raman Rice University raghav@rice.edu Jisheng Zhao Rice University jisheng.zhao@rice.edu Vivek Sarkar Rice University
Research on the Static Analysis Method of the Localization Embedded Platform Software Code Zhijie Gaoa, Ling Lu, Wen Jiao
6th International Conference on Information Engineering for Mechanics and Materials (ICIMM 2016) Research on the Static Analysis Method of the Localization Embedded Platform Software Code Zhijie Gaoa,
Real-Time Automatic Detection of Stuck Transactions
Real-Time Automatic Detection of Stuck Transactions Diploma thesis subject of Peter Hofer (0855349) in cooperation with Compuware Austria GmbH September 2012 Abstract The execution of business transactions
1 Publishable Summary
1 Publishable Summary 1.1 VELOX Motivation and Goals The current trend in designing processors with multiple cores, where cores operate in parallel and each of them supports multiple threads, makes the
On Meaning Preservation of a Calculus of Records
On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract
Predicting Null-Pointer Dereferences in Concurrent Programs. Parthasarathy Madhusudan Niloofar Razavi Francesco Sorrentino
Predicting Null-Pointer Dereferences in Concurrent Programs After work by: Azadeh Farzan Parthasarathy Madhusudan Niloofar Razavi Francesco Sorrentino Overview The problem The idea The solution The evaluation
Analysis and Monitoring of Transactional Memory Programs STSM Scientific Report
Analysis and Monitoring of Transactional Memory Programs STSM Scientific Report Jan Fiedor FIT, Brno University of Technology, Czech Republic ifiedor@fit.vutbr.cz Reference Number COST-STSM-IC1001-14636
Prediction of Coverage of Expensive Concurrency Metrics Using Cheaper Metrics
Prediction of Coverage of Expensive Concurrency Metrics Using Cheaper Metrics Bohuslav Křena, Hana Pluháčková, Shmuel Ur, and Tomáš Vojnar IT4Innovations Centre of Excellence, FIT, Brno University of Technology,
Lecture Notes on Program Equivalence
Lecture Notes on Program Equivalence 15-312: Foundations of Programming Languages Frank Pfenning Lecture 24 November 30, 2004 When are two programs equal? Without much reflection one might say that two
Efficient Data Race Detection for Unified Parallel C
P A R A L L E L C O M P U T I N G L A B O R A T O R Y Efficient Data Race Detection for Unified Parallel C ParLab Winter Retreat 1/14/2011" Costin Iancu, LBL" Nick Jalbert, UC Berkeley" Chang-Seo Park,
Correctness Criteria Beyond Serializability
Correctness Criteria Beyond Serializability Mourad Ouzzani Cyber Center, Purdue University http://www.cs.purdue.edu/homes/mourad/ Brahim Medjahed Department of Computer & Information Science, The University
Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.
Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 20 Concurrency Control Part -1 Foundations for concurrency
Testing Concurrent Java Programs Using Randomized Scheduling
Testing Concurrent Java Programs Using Randomized Scheduling Scott D. Stoller Computer Science Department State University of New York at Stony Brook http://www.cs.sunysb.edu/ stoller/ 1 Goal Pillars of
Part IV: Exploiting Purity for Atomicity
Busy Acquire Part IV: Exploiting Purity for Atomicity atomic void busy_acquire() { if (CAS(m,0,1)) break; CAS(m,0,1) CAS(m,0,1) CAS(m,0,1) (fails) (fails) (succeeds) boolean b[max]; // b[i]==true iff block
Race Directed Random Testing of Concurrent Programs
Race Directed Random Testing of Concurrent Programs Koushik Sen EECS Department, UC Berkeley, CA, USA. ksen@cs.berkeley.edu Abstract Bugs in multi-threaded programs often arise due to data races. Numerous
Valor: Efficient, Software-Only Region Conflict Exceptions
to Reuse * * Evaluated * OOPSLA * Artifact * AEC Valor: Efficient, Software-Only Region Conflict Exceptions Swarnendu Biswas Minjia Zhang Michael D. Bond Brandon Lucia Ohio State University (USA) Carnegie
Defining a Catalog of Programming Anti-Patterns for Concurrent Java
Defining a Catalog of Programming Anti-Patterns for Concurrent Java Jeremy S. Bradbury, Kevin Jalbert Software Quality Research Group Faculty of Science (Computer Science) University of Ontario Institute
An Eclipse Plug-in for Model Checking
An Eclipse Plug-in for Model Checking Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala Electrical Engineering and Computer Sciences University of California, Berkeley, USA Rupak Majumdar Computer Science
1 Introduction. 3 Syntax
CS 6110 S18 Lecture 19 Typed λ-calculus 1 Introduction Type checking is a lightweight technique for proving simple properties of programs. Unlike theorem-proving techniques based on axiomatic semantics,
1. Introduction to Concurrent Programming
1. Introduction to Concurrent Programming A concurrent program contains two or more threads that execute concurrently and work together to perform some task. When a program is executed, the operating system
Concurrent & Distributed Systems Supervision Exercises
Concurrent & Distributed Systems Supervision Exercises Stephen Kell Stephen.Kell@cl.cam.ac.uk November 9, 2009 These exercises are intended to cover all the main points of understanding in the lecture
Marathon: Detecting Atomic-Set Serializability Violations with Conflict Graphs
Marathon: Detecting Atomic-Set Serializability Violations with Conflict Graphs William N. Sumner 1, Christian Hammer 1,2, and Julian Dolby 3 1 Purdue University, West Lafayette, IN, USA wsumner@cs.purdue.edu
Deterministic Parallel Programming
Deterministic Parallel Programming Concepts and Practices 04/2011 1 How hard is parallel programming What s the result of this program? What is data race? Should data races be allowed? Initially x = 0
Reinhard v. Hanxleden 1, Michael Mendler 2, J. Aguado 2, Björn Duderstadt 1, Insa Fuhrmann 1, Christian Motika 1, Stephen Mercer 3 and Owen Brian 3
Sequentially Constructive Concurrency * A conservative extension of the Synchronous Model of Computation Reinhard v. Hanxleden, Michael Mendler 2, J. Aguado 2, Björn Duderstadt, Insa Fuhrmann, Christian
Synchronizing the Asynchronous
Synchronizing the Asynchronous Bernhard Kragl IST Austria Shaz Qadeer Microsoft Thomas A. Henzinger IST Austria Concurrency is Ubiquitous Asynchronous Concurrency is Ubiquitous Asynchronous programs are
Beyond Reduction... Busy Acquire. Busy Acquire. alloc. alloc. Non-Serial Execution: Serial Execution: Atomic but not reducible
Busy Acquire Beyond Reduction... if (CAS(m,0,1)) break; if (m == 0) { m = 1; return true; else { return false; 1 2 Busy Acquire if (CAS(m,0,1)) break; Non-Serial Execution: (fails) (fails) (succeeds) Serial
Summary: Issues / Open Questions:
Summary: The paper introduces Transitional Locking II (TL2), a Software Transactional Memory (STM) algorithm, which tries to overcomes most of the safety and performance issues of former STM implementations.
Enabling Loop Parallelization with Decoupled Software Pipelining in LLVM: Final Report
Enabling Loop Parallelization with Decoupled Software Pipelining in LLVM: Final Report Ameya Velingker and Dougal J. Sutherland {avelingk, dsutherl}@cs.cmu.edu http://www.cs.cmu.edu/~avelingk/compilers/
Do you have to reproduce the bug on the first replay attempt?
Do you have to reproduce the bug on the first replay attempt? PRES: Probabilistic Replay with Execution Sketching on Multiprocessors Soyeon Park, Yuanyuan Zhou University of California, San Diego Weiwei
Software Speculative Multithreading for Java
Software Speculative Multithreading for Java Christopher J.F. Pickett and Clark Verbrugge School of Computer Science, McGill University {cpicke,clump}@sable.mcgill.ca Allan Kielstra IBM Toronto Lab kielstra@ca.ibm.com
Lecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
Causal Atomicity. Azadeh Farzan P. Madhusudan Department of Computer Science, University of Illinois at Urbana-Champaign.
Causal Atomicity Azadeh Farzan P. Madhusudan Department of Computer Science, University of Illinois at Urbana-Champaign. {afarzan,madhu}@cs.uiuc.edu Abstract. Atomicity is an important generic specification
Memory model for multithreaded C++: August 2005 status update
Document Number: WG21/N1876=J16/05-0136 Date: 2005-08-26 Reply to: Hans Boehm Hans.Boehm@hp.com 1501 Page Mill Rd., MS 1138 Palo Alto CA 94304 USA Memory model for multithreaded C++: August 2005 status
3.4 Deduction and Evaluation: Tools Conditional-Equational Logic
3.4 Deduction and Evaluation: Tools 3.4.1 Conditional-Equational Logic The general definition of a formal specification from above was based on the existence of a precisely defined semantics for the syntax
junit RV Adding Runtime Verification to junit
junit RV Adding Runtime Verification to junit Normann Decker, Martin Leucker, and Daniel Thoma Institute for Software Engineering and Programming Languages Universität zu Lübeck, Germany {decker, leucker,