Results 1  10
of
11
Parameterized verification of transactional memories
 In PLDI ’10: Proc. 2010 ACM SIGPLAN Conf. on Programming Language Design and Implementation
, 2010
"... We describe an automatic verification method to check whether transactional memories ensure strict serializability—a key property assumed of the transactional interface. Our main contribution is a technique for effectively verifying parameterized systems. The technique merges ideas from parameterize ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
We describe an automatic verification method to check whether transactional memories ensure strict serializability—a key property assumed of the transactional interface. Our main contribution is a technique for effectively verifying parameterized systems. The technique merges ideas from parameterized hardware and protocol verification—verification by invisible invariants and symmetry reduction—with ideas from software verification—templatebased invariant generation and satisfiability checking for quantified formulæ (modulo theories). The combination enables us to precisely model and analyze unbounded systems while taming state explosion. Our technique enables automated proofs that twophase locking (TPL), dynamic software transactional memory (DSTM), and transactional locking II (TL2) systems ensure strict serializability. The verification is challenging since the systems are unbounded in several dimensions: the number and length of concurrently executing transactions, and the size of the shared memory they access, have no finite limit. In contrast, stateoftheart software model checking tools such as BLAST and TVLA are unable to validate either system, due to inherent expressiveness limitations or state explosion.
Transactions in the Jungle
, 2010
"... Transactional memory (TM) has shown potential to simplify the task of writing concurrent programs. Inspired by classical work on databases, formal definitions of the semantics of TM executions have been proposed. Many of these definitions assumed that accesses to shared data are solely performed thr ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
(Show Context)
Transactional memory (TM) has shown potential to simplify the task of writing concurrent programs. Inspired by classical work on databases, formal definitions of the semantics of TM executions have been proposed. Many of these definitions assumed that accesses to shared data are solely performed through transactions. In practice, due to legacy code and concurrency libraries, transactions in a TM have to share data with nontransactional operations. The semantics of such interaction, while widely discussed by practitioners, lacks a clear formal specification. Those interactions can vary, sometimes in subtle ways, between TM implementations and underlying memory models. We propose a correctness condition for TMs, parametrized opacity, to formally capture the now folklore notion of strong atomicity by stipulating the two following intuitive requirements: first, every transaction appears as if it is executed instantaneously with respect to other transactions and nontransactional operations, and second, nontransactional operations conform to the given underlying memory model. We investigate the inherent cost of implementing parametrized opacity. We first prove that parametrized opacity requires either instrumenting nontransactional operations (for most memory models) or writing to memory by transactions using potentially expensive readmodifywrite instructions (such as compareandswap). Then, we show that for a class of practical relaxed memory models, parametrized opacity can indeed be implemented with constanttime instrumentation of nontransactional writes and no instrumentation of nontransactional reads. We show that, in practice, parametrizing the notion of correctness allows developing more efficient TM implementations.
On the Correctness of Transactional Memory Algorithms by
, 2014
"... Transactional Memory (TM) provides programmers with a highlevel and composable concurrency control abstraction. The correct execution of client programs using TM is directly dependent on the correctness of the TM algorithms. In return for the simpler programming model, designing a correct TM algori ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
(Show Context)
Transactional Memory (TM) provides programmers with a highlevel and composable concurrency control abstraction. The correct execution of client programs using TM is directly dependent on the correctness of the TM algorithms. In return for the simpler programming model, designing a correct TM algorithm is an art. This dissertation contributes to the specification, safety criterion, testing and verification of TM algorithms. In particular, it presents techniques to prove the correctness or incorrectness of TM algorithms. We introduce a language for architectureindependent specification of synchronization algorithms. An algorithm specification captures two abstract properties of the algorithm namely the type of the used synchronization objects and the pairs of method calls that should preserve their program order in the relaxed execution. Decomposition of the correctness condition supports modular and scalable verification. We introduce the markability correctness condition as the conjunction of three intuitive invariants: writeobservation, readpreservation and realtimepreservation. We prove the equivalence of markability and opacity correctness conditions. We identify two pitfalls that lead to violation of opacity: the writeskew and writeexposure
Proving Nonopacity
"... Guerraoui and Kapalka defined opacity as a safety criterion for transactional memory algorithms in 2008. Researchers have shown how to prove opacity, while little is known about pitfalls that can lead to nonopacity. In this paper, we identify two problems that lead to nonopacity and we prove an im ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
(Show Context)
Guerraoui and Kapalka defined opacity as a safety criterion for transactional memory algorithms in 2008. Researchers have shown how to prove opacity, while little is known about pitfalls that can lead to nonopacity. In this paper, we identify two problems that lead to nonopacity and we prove an impossibility result. We first show that the wellknown TM algorithms DSTM and McRT don’t satisfy opacity. DSTM suffers from a writeskew anomaly, while McRT suffers from a writeexposure anomaly. We then prove that for directupdate TM algorithms, opacity is incompatible with a liveness criterion called local progress, even for faultfree systems. Our result implies that if TM algorithm designers want both opacity and local progress, they should avoid directupdate algorithms. 1.
Towards Formally Specifying and Verifying 1,2 Transactional Memory
, 2009
"... We describe ongoing work in which we aim to formally specify a correctness condition for transactional memory (TM) called Weakest Reasonable Condition (WRC), and to facilitate fully formal and machinechecked proofs that TM implementations satisfy the condition. To precisely define the WRC condition, ..."
Abstract
 Add to MetaCart
(Show Context)
We describe ongoing work in which we aim to formally specify a correctness condition for transactional memory (TM) called Weakest Reasonable Condition (WRC), and to facilitate fully formal and machinechecked proofs that TM implementations satisfy the condition. To precisely define the WRC condition, we express it using an I/O automaton. We similarly present another condition, called PRAG, which is more restrictive, but more closely reflects intuition about common TM implementation techniques. We sketch a simulation proof that PRAG implements WRC, allowing ourselves and others to focus more pragmatically on proofs of such implementations. We are working on modeling these conditions in the PVS language so that we can construct and check such proofs precisely and mechanically. We are also working towards proving that some popular TM implementations satisfy the PRAG condition, starting with simple coarsegrained versions and refining them to model realistic implementations.
Extensible Transactional Memory Testbed
, 2009
"... Transactional Memory (TM) is a promising abstraction as it hides all synchronization complexities from the programmers of concurrent applications. More particularly the TM paradigm operated a complexity shift from the application programming to the TM programming. Therefore, expert programmers have ..."
Abstract
 Add to MetaCart
Transactional Memory (TM) is a promising abstraction as it hides all synchronization complexities from the programmers of concurrent applications. More particularly the TM paradigm operated a complexity shift from the application programming to the TM programming. Therefore, expert programmers have now started to look for the ideal TM that will bring, onceforall, performance to all concurrent applications. Researchers have recently identified numerous issues TMs may suffer from. Surprisingly, no TMs have ever been tested in these scenarios. In this paper, we present the first to date TM testbed. We propose a framework, TMunit, that provides a domain specific language to write rapidly TM workloads so that our testsuite is easily extensible. Our reproducible semantic tests indicate through reproducible counterexamples that existing TMs do not satisfy recent consistency criteria. Our performance tests identify workloads where wellknown TMs perform differently. Finally, additional tests indicate some workloads preventing contention managers from progressing.
ABSTRACT OF THE DISSERTATION On the Correctness of Transactional Memory Algorithms
, 2014
"... Transactional Memory (TM) provides programmers with a highlevel and composable concurrency control abstraction. The correct execution of client programs using TM is directly dependent on the correctness of the TM algorithms. In return for the simpler programming model, designing a correct TM algori ..."
Abstract
 Add to MetaCart
Transactional Memory (TM) provides programmers with a highlevel and composable concurrency control abstraction. The correct execution of client programs using TM is directly dependent on the correctness of the TM algorithms. In return for the simpler programming model, designing a correct TM algorithm is an art. This dissertation contributes to the specification, safety criterion, testing and verification of TM algorithms. In particular, it presents techniques to prove the correctness or incorrectness of TM algorithms. We introduce a language for architectureindependent specification of synchronization algorithms. An algorithm specification captures two abstract properties of the algorithm namely the type of the used synchronization objects and the pairs of method calls that should preserve their program order in the relaxed execution. Decomposition of the correctness condition supports modular and scalable verification. We introduce the markability correctness condition as the conjunction of three intuitive invariants: writeobservation, readpreservation and realtimepreservation. We prove the equivalence of markability and opacity correctness conditions. We identify two pitfalls that lead to violation of opacity: the writeskew and writeexposure
Form Methods Syst Des (2011) 39:297–331 DOI 10.1007/s1070301101313 Verification of STM on relaxed memory models
, 2011
"... Abstract Software transactional memories (STM) are described in the literature with assumptions of sequentially consistent program execution and atomicity of high level operations like read, write, and abort. However, in a realistic setting, processors use relaxed memory models to optimize hardwar ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract Software transactional memories (STM) are described in the literature with assumptions of sequentially consistent program execution and atomicity of high level operations like read, write, and abort. However, in a realistic setting, processors use relaxed memory models to optimize hardware performance. Moreover, the atomicity of operations depends on the underlying hardware. This paper presents the first approach to verify STMs under relaxed memory models with atomicity of 32 bit loads and stores, and readmodifywrite operations. We describe RML, a simple language for expressing concurrent programs. We develop a semantics of RML parametrized by a relaxed memory model. We then present our tool, FOIL, which takes as input the RML description of an STM algorithm restricted to two threads and two variables, and the description of a memory model, and automatically determines the locations of fences, which if inserted, ensure the correctness of the restricted STM algorithm under the given memory model. We use FOIL to verify DSTM, TL2, and McRT STM under the memory models of sequential consistency, total store order, partial store order, and relaxed memory order for two threads and two variables. Finally, we extend the verification results for DSTM and TL2 to an arbitrary number of threads and variables by manually proving that the structural properties of STMs are satisfied at the hardware level of atomicity under the considered relaxed memory models.
Noname manuscript No. (will be inserted by the editor) 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 red ..."
Abstract
 Add to MetaCart
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 finitestate problem, and we illustrate the use of the method by proving the correctness of several TMs, including twophase 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 finitestate transition systems, a nondeterministic transition system repThis 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].
Decomposing Opacity
"... Abstract. Transactional memory (TM) algorithms are subtle and the TM correctness conditions are intricate. Decomposition of the correctness condition can bring modularity to TM algorithm design and verification. We present a decomposition of opacity called markability as a conjunction of separate in ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. Transactional memory (TM) algorithms are subtle and the TM correctness conditions are intricate. Decomposition of the correctness condition can bring modularity to TM algorithm design and verification. We present a decomposition of opacity called markability as a conjunction of separate intuitive invariants. We prove the equivalence of opacity and markability. The proofs of markability of TM algorithms can be aided by and mirror the algorithm design intuitions. As an example, we prove the markability and hence opacity of the TL2 algorithm. In addition, based on one of the invariants, we present lower bound results for the time complexity of TM algorithms. 1