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 can be supported by a framework that detects 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, a method that is called without first checking that a latch is open) are easier to reason about 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 Java as the target language. Our objective is to allow programmers to express their intents by using mechanisms from a concurrency library (inspired by java.util.concurrent) in which specific patterns 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. We are implementing runtime support so that 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. We are also exploring static checking and compile-time analysis of intent violations.

The project addresses three primary research questions:

  1. What intents can be associated with building blocks, such as synchronizers, 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?

The key innovations in our approach are the light annotation burden that results from embedding intents in a carefully designed concurrency library and the guarantees that a runtime-checking framework does not issue false-positives.