Intentional Concurrent Programming

(in collaboration with Phil Hatcher)

Concurrent programming is notoriously difficult and a major reason for this is the intricacy of testing and debugging concurrent programs. Both activities are made challenging by the inherent nondeterminism of these programs: Intensive testing can miss serious bugs, and observed incorrect behaviors can be difficult to reproduce.

We propose to address this difficulty by providing support for intentional concurrent programming, an approach that requires that programmers explicitly express their intent (as it relates to concurrency). Intentional concurrent programming is supported by an execution framework that can detect when an intent is being violated, before this violation results in an observable bug. Intent violations (e.g., a thread accessing data it is not supposed to access) are easier to produce (in testing) and reproduce than the actual concurrency bugs potentially triggered by the race condition that is the result of the intent violation.

Our project defines and evaluates a model for intentional concurrent programming. It uses a custom-made compiler for the ECMAScript 5.1 language specification, extended to support threads and the specification of intents. We named the resulting language Tscript. Our compiler generates code that runs on the Java Virtual Machine and that includes run-time checking of intent violations. Programmers express their intents by using mechanisms from a concurrency library in which specific intents have been embedded. For instance, private objects can only be accessed by a single thread, immutable objects can only be read (by all threads) but not written, shared mutable objects must be explicitly guarded by locks, etc. Any access to an object that violates an intent results in a run-time exception, whether this access triggers a race condition bug or not.

The project addresses three primary research questions:

  1. What intents can be associated with building blocks, as they are commonly found in concurrency libraries?
  2. Is our model expressive enough to convey those intents, with limited burden on the programmer?
  3. What classes of concurrency bugs does the model aid in detecting?

As part of this exploration, we are implementing an intent-aware library (modeled after the Java concurrency library) that supports synchronizers, non-blocking concurrent data structures and task execution frameworks (we also plan to implement an event-driven version of the library); we use the compiler and libraries to implement and evaluate a set of concurrent benchmarks; we study and classify the concurrency bugs we encounter and how our frameworks handles them; and we employ compiler optimization techniques to reduce the overhead of the access checks.

The key innovation in our approach is our insight that the well-known problem of annotation burden can be eliminated by embedding nearly all specifications of intent within a carefully designed concurrency library. In addition, our model eliminates all false-positive error reports and results in a very easy to understand memory model.