A History of BlockingQueues

This paper describes a way to formally specify the behaviour of concurrent data structures. When specifying concurrent data structures, the main challenge is to make specifications stable, i.e., to ensure that they cannot be invalidated by other threads. To this end, we propose to use history-based specifications: instead of describing method behaviour in terms of the object’s state, we specify it in terms of the object’s state history. A history is defined as a list of state updates, which at all points can be related to the actual object’s state. We illustrate the approach on the BlockingQueue hierarchy from the java.util.concurrent library. We show how the behaviour of the interface BlockingQueue is specified, leaving a few decisions open to descendant classes. The classes implementing the interface correctly inherit the specifications. As a specification language, we use a combination of JML and permission-based separation logic, including abstract predicates. This results in an abstract, modular and natural way to specify the behaviour of concurrent queues. The specifications can be used to derive high-level properties about queues, for example to show that the order of elements is preserved. Moreover, the approach can be easily adapted to other concurrent data structures.

💡 Research Summary

The paper tackles the long‑standing problem of specifying concurrent data structures in a way that remains stable under interference from other threads. Traditional specifications describe a method’s effect in terms of the object’s current state; when another thread mutates that state the specification can become invalid. To overcome this, the authors introduce a history‑based specification technique. A “history” is defined as an ordered list of state‑update events (insertions, removals, wait‑start, wait‑end, etc.). At any moment the concrete state of the object must be consistent with its history, a relationship captured by a “history‑compatible” invariant. By reasoning about histories rather than instantaneous states, method contracts become immune to concurrent modifications.

The specification language combines JML (Java Modeling Language) with permission‑based separation logic. JML supplies the familiar pre‑ and post‑conditions, while the permission logic explicitly tracks which thread holds read or write rights to each part of the object. Abstract predicates are used to hide the concrete mapping between a history and the actual data structure, allowing the same high‑level contract to be inherited by all subclasses.

The authors apply the approach to the java.util.concurrent BlockingQueue hierarchy. The interface specification consists of four main components:

1. Core invariant – the head and tail indices of the queue correspond to the first and last insertion events in the history list.
2. Method contracts – for each public operation (put, take, offer, poll, etc.) a precise description of how the history is updated. For example, put(e) appends an “insert(e)” event to the history and guarantees that the concrete queue now contains e at the tail; take() removes the oldest “insert” event and returns its element.
3. Blocking semantics – when a thread blocks because the queue is full or empty, the history records a “wait‑start” event and later a “wait‑end” event. This ensures that the waiting thread’s contract is not broken by actions of other threads.
4. Implementation inheritance – concrete classes such as ArrayBlockingQueue, LinkedBlockingQueue, and PriorityBlockingQueue inherit the interface contracts unchanged. Each class provides its own concrete mapping between the abstract history and its internal representation (array, linked list, heap), but must preserve the invariant and the method‑level history updates.

Using these specifications the authors formally prove high‑level properties. The most notable is order preservation: because the history records insertions in exact FIFO order, any take operation must return the element associated with the earliest insertion event that has not yet been removed. This proof holds regardless of the underlying synchronization mechanism, demonstrating that the specification captures the essential semantics of a blocking queue.

Beyond queues, the paper argues that the technique generalises to other concurrent containers such as stacks, maps, and sets. By defining appropriate event types and consistency invariants, one can obtain stable, modular specifications for a wide range of data structures. Moreover, the history itself serves as an execution trace, making it valuable for model checking and automated testing tools that explore all possible interleavings.

In summary, the contribution is a novel, history‑centric specification framework that combines JML’s expressive contracts with permission‑based separation logic to achieve stable, modular, and reusable specifications for concurrent collections. The case study on BlockingQueue demonstrates that the approach can capture both functional behavior (FIFO ordering) and concurrency aspects (blocking, wake‑up) in a single, compositional model, offering a practical path toward more reliable verification of multithreaded Java programs.