Model checking transactional memories

Abstract

Model checking transactional memories (TMs) is difficult because of the unbounded number, length, and delay of concurrent transactions, as well as the unbounded size of the memory. We show that, under certain conditions satisfied by most TMs we know of, the model checking problem can be reduced to a finite-state problem, and we illustrate the use of the method by proving the correctness of several TMs, including two-phase locking, DSTM, and TL2. The safety properties we consider include strict serializability and opacity; the liveness properties include obstruction freedom, livelock freedom, and wait freedom. Our main contribution lies in the structure of the proofs, which are largely automated and not restricted to the TMs mentioned above. In a first step we show that every TM that enjoys certain structural properties either violates a requirement on some program with two threads and two shared variables, or satisfies the requirement on all programs. In the second step, we use a model checker to prove the requirement for the TM applied to a most general program with two threads and two variables. In the safety case, the model checker checks language inclusion between two finite-state transition systems, a nondeterministic transition system representing the given TM applied to a most general program, and a deterministic transition system This research was supported by the Swiss National Science Foundation. This paper is an extended and revised version of our previous work on model checking transactional memories [11,12].R. Guerraoui representing a most liberal safe TM applied to the same program. The given TM transition system is nondeterministic because a TM can be used with different contention managers, which resolve conflicts differently. In the liveness case, the model checker analyzes fairness conditions on the given TM transition system.

Software Transactional Memory on Relaxed Memory Models

“…Thus, these two properties can be directly used in our framework. The property P1, transactional projection, originally [6] stated that aborting and pending transactions have no influence on committing transactions, and can thus be projected away. This holds for deferred-update STMs as an aborted transaction does not write to any variable v of the transactional program.…”

“…On the other hand, pending transactions can be projected away in a coarse grained alphabet [6], but not in our fine-grained alphabet due to the fact that a pending transaction may be in the process of committing values to memory. Furthermore, we generalize P4, the monotonicity property, to handle any number of pending transactions, as opposed to just one pending transaction in the original property [6]. Note that although this generalization is possible for opacity, it cannot be extended to some weaker properties, like strict serializability.…”

“…Previous attempts at formally verifying the correctness of STMs [3,6,7] with respect to different correctness criteria assumed that high-level transactional commands like start, read, write, commit, and abort execute atomically and in a sequentially consistent manner. Verification of an STM at this level of abstraction leaves much room for errors in a realistic setting.…”

“…Not surprisingly, when compared to verifying an STM at a high-level atomic alphabet, the level of non-determinism to be dealt with at hardware-level atomicity under a relaxed memory model is much higher. For example, the implementation of DSTM [10] with 2 threads and 2 variables generates 1,000 states with a high-level atomic alphabet [6] and 1,200,000 states with a low-level one, even on a sequentially consistent memory model. A relaxed memory model further increases the state space.…”

“…The reason for choosing these memory models is to capture different levels of relaxations allowed by different multiprocessors. Unlike earlier formalisms [3,6] used for verification, our formalism can be used to express and check the correctness of STMs with both update semantics: direct (eager) and deferred (lazy). Then, we present a new language, RML (Relaxed Memory Language), with a hardwarelevel of atomicity, whose semantics is parametrized by various relaxed memory models.…”