A simple abstraction for complex concurrent indexes

Abstract

Indexes are ubiquitous. Examples include associative arrays, dictionaries, maps and hashes used in applications such as databases, file systems and dynamic languages. Abstractly, a sequential index can be viewed as a partial function from keys to values. Values can be queried by their keys, and the index can be mutated by adding or removing mappings. Whilst appealingly simple, this abstract specification is insufficient for reasoning about indexes that are accessed concurrently.We present an abstract specification for concurrent indexes. We verify several representative concurrent client applications using our specification, demonstrating that clients can reason abstractly without having to consider specific underlying implementations. Our specification would, however, mean nothing if it were not satisfied by standard implementations of concurrent indexes. We verify that our specification is satisfied by algorithms based on linked lists, hash tables and B Link trees. The complexity of these algorithms, in particular the B Link tree algorithm, can be completely hidden from the client's view by our abstract specification.General Terms Algorithms, Concurrency, Theory, Verification.

Go with the flow: compositional abstractions for concurrent data structures

“…The abstractions provided by these logics are orthogonal to the ones developed here. These logics have been used, e.g., to verify specifications of concurrent dictionary implementations based on B-trees and skip lists that enable compositional client verification [da Rocha Pinto et al 2011;Xiong et al 2017]. We believe that the proofs developed in [Xiong et al 2017] can be further simplified by introducing flow interfaces as an intermediate abstraction of the considered data structures.…”

Hoare-style specifications as correctness conditions for non-linearizable concurrent objects

“…The spec of flip2 is defined with respect to history χ F : (8) It says that the return value res is equal to the sum of binary complementsā +b for the thread's two separate selfcontributions to the history. Due to the effects of the interference, the history entries a and b may be separated in the overall history by the contributions of the environment, as indicated by .…”

“…For example, Figure 1 shows a proof sketch for a toy program that uses both exchange and flip2. As each of these methods requires its own auxiliary history variable (χ E for the exchanger, and χ F for flip2), the combined program uses both, but the proof simply ignores those histories that are not relevant for any specific method (i.e., we can "frame" the specs (7) and (8) wrt. the histories of the objects that they do not depend upon).…”

“…The conditional (line 12) checks if the exchange was successful, and if so, assigns the sum of exchanged values to t (line 14); otherwise t gets assigned 2. We want to prove via the specs (7) and (8), that in the absence of external interference on the flip2's pointer x and the exchanger, the outcome is always t = 2. Explaining the verification In addition to the absence of external interference, we assume that the initial value of x is 0, and the initial self -histories for both flip2 and exchange are empty (line 1).…”

“…Explaining the verification In addition to the absence of external interference, we assume that the initial value of x is 0, and the initial self -histories for both flip2 and exchange are empty (line 1). Once the flip2 threads are forked, we employ spec (8) for each of them, simply ignoring (i.e., framing out) χ E , as this history variable does not apply to them flip2. Upon finishing, the postconditions of flip2 in line 4 capture the relationship between the contributions to the history χ F and the results r 1 and r 2 of the two calls.…”