Dynamically checking ownership policies in concurrent c/c++ programs

Abstract

Concurrent programming errors arise when threads share data incorrectly. Programmers often avoid these errors by using synchronization to enforce a simple ownership policy: data is either owned exclusively by a thread that can read or write the data, or it is read owned by a set of threads that can read but not write the data. Unfortunately, incorrect synchronization often fails to enforce these policies and memory errors in languages like C and C++ can violate these policies even when synchronization is correct. In this paper, we present a dynamic analysis for checking ownership policies in concurrent C and C++ programs despite memory errors. The analysis can be used to find errors in commodity multi-threaded programs and to prevent attacks that exploit these errors. We require programmers to write ownership assertions that describe the sharing policies used by different parts of the program. These policies may change over time, as may the policies' means of enforcement, whether it be locks, barriers, thread joins, etc. Our compiler inserts checks in the program that signal an error if these policies are violated at runtime. We evaluated our tool on several benchmark programs. The run-time overhead was reasonable: between 0 and 49% with an average of 26%. We also found the tool easy to use: the total number of ownership assertions is small, and the asserted specification and implementation can be debugged together by running the instrumented program and addressing the errors that arise. Our approach enjoys a pleasing modular soundness property: if a thread executes a sequence of statements on variables it owns, the statements are serializable within a valid execution, and thus their effects can be reasoned about in isolation from other threads in the program.

Composable, nestable, pessimistic atomic statements

“…The programmer must ensure that data is shared correctly using consistent mechanisms. Our own previous work in SharC uses sharing annotations on all types [5], while Martin et al [24] use dynamic ownership assertions to detect where such rules are violated. Furthermore, external libraries may already use locks to protect their own data -converting these libraries to use shelters may not be desirable, practical or even possible.…”

Composable specifications for structured shared-memory communication

“…Shoal [4] builds on SharC and lets programmers assign rules to entire data-structures, as opposed to individual objects. More recently, Martin et al [27] present an annotation technique for C/C++ programs that lets programmers declare dataownership properties (which threads own which data). As in our work, they use a dynamic tool to check specifications.…”

PUSh

“…the various alternatives, one approach to detecting data races is to require the programmer to specify the intended sharing, using special annotations, and detect accesses that violate these intentions [11,12,15,22,24,25,33]. Especially for languages like C and C++, this approach can simplify and reduce the overhead of data race detection since tools based on this approach do not need to autonomously differentiate between accesses that correspond to intended sharing and those that violate these intentions.…”

“…The data race detectors closest to our work are: SharC [11], Shoal [12], and a tool that we refer to as DCOP (Dynamically Checking Ownership Policies) [33]. All three tools use a combination of static analysis and software instrumentation of memory accesses.…”

“…We make the following contributions: 1) a novel technique for using current MMUs with MPKs for efficient data race detection by the prevention of unintended sharing coupled with happens-before tracking of only sharing policy changes; 2) several optimizations for increasing detection accuracy as well as reducing memory and performance overheads, including enhanced annotations, kernel changes, software caching, and the use of a universal family of hash functions; 3) analysis of the sources of overhead of PUSh and the effectiveness of the different optimizations; 4) comparison of PUSh to the most closely-related annotation-based race detectors schemes [11,12,33] as well as TSan.…”