Dynamic detection of atomic-set-serializability violations

Abstract

Previously we presented atomic sets, memory locations that share some consistency property, and units of work, code fragments that preserve consistency of atomic sets on which they are declared. We also proposed atomic-set serializability as a correctness criterion for concurrent programs, stating that units of work must be serializable for each atomic set. We showed that a set of problematic data access patterns characterize executions that are not atomic-set serializable. Our criterion subsumes data races (single-location atomic sets) and serializability (all locations in one set).In this paper, we present a dynamic analysis for detecting violations of atomic-set serializability. The analysis can be implemented efficiently, and does not depend on any specific synchronization mechanism. We implemented the analysis and evaluated it on a suite of real programs and benchmarks. We found a number of known errors as well as several problems not previously reported.

Finding concurrency-related bugs using random isolation

“…1 for the class Shop.) Empire uses the default assumptions of [4]: T has one atomic set containing all of T 's declared fields (one atomic set per object), and every public method of T is a unit of work for that atomic set. Additionally, any method that takes a T object as a parameter is also a unit of work.…”

“…Empire's checking algorithm uses the CPDS model checker's semi-decision procedure to (symbolically) consider multiple executions of the program. This is in contrast with the dynamic-detection approach [4], which only looks at one execution at a time.…”

“…4 In Empire, a problematic interleaving scenario with respect to a set of shared memory locations is used as an input specification to a model checker. Specifically, Empire translates a concurrent Java program into a communicating pushdown system (CPDS) [2,3], and translates the scenario into a violation monitor that checks for the occurrence of the scenario, and runs concurrently with the other CPDS processes.…”

“…A second paper [4] focused on legacy code and checking whether an existing multi-threaded program is appropriately synchronized, by dynamically detecting the occurrence of problematic interleaving scenarios. The work on Empire complements these other approaches by providing a method to statically check Java programs for problematic interleaving scenarios.…”

“…For code that satisfies certain properties, 4 it can verify the absence of violations. If the properties are not met, then it can miss errors, and thus operates as a bug detector, rather than a verification tool.…”