A Lock-based Protocol for Software Transactional Memory

The aim of a software transactional memory (STM) system is to facilitate the design of concurrent programs, i.e., programs made up of processes (or threads) that concurrently access shared objects. To that end, a STM system allows a programmer to write transactions accessing shared objects, without having to take care of the fact that these objects are concurrently accessed: the programmer is discharged from the delicate problem of concurrency management. Given a transaction, the STM system commits or aborts it. Ideally, it has to be efficient (this is measured by the number of transactions processed per time unit), while ensuring that as few transactions as possible are aborted. From a safety point of view (the one addressed in this paper), a STM system has to ensure that, whatever its fate (commit or abort), each transaction always operates on a consistent state. STM systems have recently received a great attention. Among the proposed solutions, lock-based systems and clock-based systems have been particularly investigated. This paper presents a new lock-based STM system designed from simple basic principles. Its main features are the following: it (1) does not require the shared memory to manage several versions of each object, (2) uses neither timestamps, nor version numbers, (3) aborts a transaction only when it conflicts (with some other live transaction), (4) never aborts a write only transaction, (5) employs only bounded control variables, and (6) has no centralized contention point

Progressive Transactional Memory in Time and Space

Transactional memory (TM) allows concurrent processes to organize sequences of operations on shared \emph{data items} into atomic transactions. A transaction may commit, in which case it appears to have executed sequentially or it may \emph{abort}, in which case no data item is updated. The TM programming paradigm emerged as an alternative to conventional fine-grained locking techniques, offering ease of programming and compositionality. Though typically themselves implemented using locks, TMs hide the inherent issues of lock-based synchronization behind a nice transactional programming interface. In this paper, we explore inherent time and space complexity of lock-based TMs, with a focus of the most popular class of \emph{progressive} lock-based TMs. We derive that a progressive TM might enforce a read-only transaction to perform a quadratic (in the number of the data items it reads) number of steps and access a linear number of distinct memory locations, closing the question of inherent cost of \emph{read validation} in TMs. We then show that the total number of \emph{remote memory references} (RMRs) that take place in an execution of a progressive TM in which $n$ concurrent processes perform transactions on a single data item might reach $\Omega(n \log n)$, which appears to be the first RMR complexity lower bound for transactional memory.Comment: Model of Transactional Memory identical with arXiv:1407.6876, arXiv:1502.0272

Transactional Memory: Glimmer of a Theory

Transactional memory (TM) is a promising paradigm for concurrent programming. This paper is an overview of our recent theoretical work on defining a theory of TM. We first recall some TM correctness properties and then overview results on the inherent power and limitations of TMs

A Correctness Criterion for Eager Approach Validation for Transactional Memory System

With rise of multicore systems, software transactional memory (STM) has garnered significant interest as an elegant alternative for developing concurrent code. A (memory) transaction is an unit of code in execution in memory. A software transactional memory system (STM) ensures that a transaction appears either to execute atomically (even in presence of other concurrent transactions) or to never have executed at all. To achieve this property, a commonly used approach by STM systems is eager validation approach. In this approach, when a transaction performs a write operation the update is immediately written to the memory and is visible to other transactions. If the transaction aborts, then the writes performed by it previously are undone with the aid of undo logs. In this paper, we have presented a new correctness criterion EAC for eager approach validation systems. We have developed a STM system that implements this criterion. The STM system uses database recovery criterion strictness and the notion of conflict graphs used for testing conflict serializability

WTTM 2012, The Fourth Workshop on the Theory of Transactional Memory

Abstract In conjunction with PODC 2012, the TransForm project (Marie Curie Initial Training Network) and EuroTM (COST Action IC1001) supported the 4th edition of the Workshop on the Theory of Transactional Memory (WTTM 2012). The objective of WTTM was to discuss new theoretical challenges and recent achievements in the area of transactional computing. The workshop took place on July 19, 2012, in Madeira, Portugal. This year's WTTM was a milestone event for two reasons. First, because the same year, the two seminal articles on hardware and software transactional memories Transactional memory is a concurrency control mechanism for synchronizing concurrent accesses to shared memory by different threads. It has been proposed as an alternative to lock-based synchronization to simplify concurrent programming while exhibiting good performance. The sequential code is encapsulated in transactions, which are sequences of accesses to shared or local variables that should be executed atomically by a single thread. A transaction ends either by committing, in which case all of its updates take effect, or by aborting, in which case, all its updates are discarded and never become visible to other transactions. Consistency criteria Since the introduction of the transactional memory paradigm, several consistency criteria have being proposed to capture its correct behavior. Some consistency criteria have been inherited from &0 6,*&7 1HZV 'HFHPEHU YRO QR the database field (e.g., serializability, strict serializability), others have been proposed to extend these latter to take into account aborted transactions, e.g., opacity, virtual world consistency; some others have been proposed to define the correct behavior when transactions have to be synchronized with non transactional code, e.g., strong atomicity. Among all the criteria, opacity, originally proposed by Guerraoui and Kapalka Victor Luchangco presented his joint work with Mohsen Lesani and Mark Moir provocatively titled "Putting opacity in its place" in which he presented the TMS1 and TMS2 consistency conditions and clarified their relationship with the prefix-closed definition of opacity. Broadly, these conditions ensure that no transaction observes the partial effects of any other transaction in any execution of the STM without having to force a total-order on transactions that participate in the execution. In particular, TMS1 is defined for any object with a well-defined sequential specification while TMS2 is specific for read-write registers. They further show using IO Automata While opacity defines the correctness of transactional memories when shared variables are accessed only inside transactions, understanding the interaction between transactions and locks or between accesses to shared variables in and outside transactions has been a major question. This is motivated by the fact that the code written to work in a transactional system may need to interact with legacy code where locks have been used for synchronization. It has been shown that replacing a lock with a transaction does not always ensure the same behavior. Srivatsan Ravi presented his joint work with Vincent Gramoli and Petr Kuznetsov on the locallyserializable linearizability (ls-linearizability) consistency criterion that applies to both transactionbased and lock-based programs, thus allowing to compare the amount of concurrency of a concurrent program Stephan Diestelhorst presented his preliminary work with Martin Pohlack, "Safely Accessing Timestamps in Transactions". He presented scenarios in which the access to the CPU timestamp counter inside transactions could lead to unexpected behaviors. In particular, this counter is not a transactional variable, so reading it inside a transaction can lead to a violation of the single lock atomicity semantics: multiple accesses to this counter within transactions may lead to a different result than multiple accesses within a critical section. In this talk, a solution to prevent several transactions from accessing the timestamp concurrently was also sketched. Annette Bienusa presented the definition of snapshot trace to simplify the reasoning on the correctness of TMs that ensure snapshot isolation. This is a joint work with Peter Thiemann Finally, Faith Ellen stated that despite the fact that a rich set of consistency criteria have been proposed there is no agreement on the way the semantics of a transactional memory has to be defined: operationally &0 6,*&7 1HZV 'HFHPEHU YRO QR Data structures for transactional computing Eliot Moss' talk intended to explore how the availability of transactions as a programming construct might impact the design of data types. He gave multiple examples on how to design data types having in mind that these types are going to be used in transactions. In a similar direction, Maurice Herlihy considered data types that support high-level methods and their inverse. As an example a set of elements supports the method to add an element, add(x), and the method to remove an element from the set remove(x). For these kind of data types, he discussed the possibility to apply a technique called transactional boosting which provides a modular way to make highly concurrent thread-safe data structures transactional. He suggested to distinguish the transaction-level synchronization with the thread-level synchronization. In particular, to synchronize the access to a linearizable object, non-commutative method calls have to be executed serially (e.g., add(x) and remove(x)). Two method calls are commutative if they can be applied in any order and the final state of the object does not change. For example, add(x) and remove(x) do not commute, while add(x) and add(y) commute. Since methods have inverses, recovery can be done at the granularity of methods. This technique exploits the object semantics to synchronize concurrent accesses to the object. This is expected to be more efficient than STM implementations where consistency is guaranteed by detecting read/write conflicts. Performance Improving the efficiency of TMs has been a key problem for the last few years. In fact, in order for transactional memory to be accepted as a candidate to replace locks, we need to show that it has performance comparable to these latter. In her talk Faith Ellen summarized the theoretical results on the efficiency of TMs. She stated that efficiency has been considered through three axes: properties that state under which circumstances aborts have to be avoided (permissiveness Mykhailo Laremko discussed how to apply known techniques (e.g., combining) to boost the performance of existing STM systems that have a central point of synchronization. In particular, in his joint work with Panagiota Fatourou, Eleftherios Kosmas and Giorgos E. Papadakis, they augment the NOrec transactional memory by combining and replacing the single global lock with a set of locks. They provide preliminary simulation results to compare NOrec and its augmented versions, showing that these latter perform better. Nuno Diegues with João Cachopo [6] study how to extend a transactional memory to support nested transactions efficiently. The difficulty is to take into account the constraints imposed by the baseline algorithm. To investigate different directions in the design space (lazy versus eager conflict detection, multiversion versus single version etc), they consider the following transactional memories: JVSTM[9], NesTM [3] and PNSTM 'HFHPEHU YRO QR Diegues shows that PNSTM's throughput is not affected by parallel nesting, while it is the case for the throughput of JVSTM and NesTM. In particular, NesTM shows the greater degradation of performance w.r.t. the depth of the nesting. Legacy code and hardware transactional memory The keynote by Nir Shavit was about his joint work with Yehuda Afek and Alex Matveev on "Pessimistic transactional lock-elision (PLE)" Distributed transactional memory Distributed transactional memory is the implementation of the transactional memory paradigm in a networked environment where processes communicate by exchanging messages. Differently from transactional memory for multicore machines, the networked environment needs to take into account the non negligible communication delays. To support local accesses to shared objects, distributed transactional memories usually rely on replication. Pawel T. Wojciechowski presented his joint work with Jan Konczak. They consider the problem of recovering the state of the shared data after some node crashes. This requests to write data into stable storage. Their goal was to minimize writes to stable storage, which are slow, or to do them in parallel with the execution of transactions. He presented a crash-recovery model for distributed transactional memory which is based on deferred update replication relying on atomic broadcast. Their model takes into account the tradeoff between performance and fault-tolerance. See Sebastiano Peluso claimed that efficient replication schemes for distributed transactional memory have to follow three design principles: partial replication, genuineness to ensure scalability and support for wait-free read-only transactions. According to genuineness the only nodes involved in the execution of a transaction are ones that maintain a replica of an object accessed by the transaction. He claimed that genuineness is a fundamental property for the scalability of distributed transactional memory. This is a joint work with Paolo Romano and Francesco Quaglia &0 6,*&7 1HZV 'HFHPEHU YRO QR Conclusion While transactional memory has become a practical technology integrated in the hardware of the IBM BlueGene/Q supercomputer and the upcoming Intel Haswell processors, the theory of transactional memory still misses good models of computation, good complexity measures, agreement on the right definitions, identification of fundamental and useful algorithmic questions, innovative algorithm designs and lower bounds on problems. Upcoming challenges will likely include the design of new transactional algorithms that exploit the low-overhead of low-level instructions on the one hand, and the concurrency of high-level data types on the other hand. For further information the abstracts and slides of the talks can be found at http://sydney.edu.au/engineering/it/˜gramoli/events/wttm4. Acknowledgements We are grateful to the speakers, to the program committee members of WTTM 2012 for their help in reviewing this year's submissions and to Panagiota Fatourou for her help in the organization of the event. We would like to thank Srivatsan Ravi and Mykhailo Laremko for sharing their notes on the talks of the workshop

On the Consistency Conditions of Transactional Memories

The aim of a Software Transactional Memory (STM) is to discharge the programmers from the management of synchronization in multiprocess programs that access concurrent objects. To that end, a STM system provides the programmer with the concept of a transaction: each sequential process is decomposed into transactions, where a transaction encapsulates a piece of sequential code accessing concurrent objects. A transaction contains no explicit synchronization statement and appears as if it has been executed atomically. Due to the underlying concurrency management, a transaction commits or aborts. Up to now, few papers focused on the definition of consistency conditions suited to STM systems. One of them has recently proposed the opacity consistency condition. Opacity involves all the transactions (i.e., the committed plus the aborted transactions). It requires that (1) until it aborts (if ever it does) a transaction sees a consistent global state of the concurrent objects, and (2) the execution is linearizable (i.e., it could have been produced by a sequential execution -of the same transactions- that respects the real time order on the non-concurrent transactions). This paper is on consistency conditions for transactional memories. It first presents a framework that allows defining a space of consistency conditions whose extreme endpoints are serializability and opacity. It then extracts from this framework a new consistency condition that we call virtual world consistency. This condition ensures that (1) each transaction (committed or aborted) reads values from a consistent global state, (2) the consistent global states read by committed transactions are mutually consistent, but (3) the consistent global states read by aborted transactions are not required to be mutually consistent. Interestingly enough, this consistency condition can benefit lots of STM applications as, from its local point of view, a transaction cannot differentiate it from opacity. Finally, the paper presents and proves correct a STM algorithm that implements the virtual world consistency condition. Interestingly, this algorithm distinguishes the serialization date of a transaction from its commit date (thereby allowing more transactions to commit)

Robust Verteilte Software Transaktionen für Haskell

This thesis motivates and develops a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. They either control geographically wide spread hardware resources or utilize redundant hardware components to minimize system failure. STM is an abstraction for synchronizing shared resources in concurrent applications. It helps to prevent deadlocks and thus facilitates composing program code. We extend the STM abstraction to distributed systems and present an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task.Die vorliegende Arbeit motiviert und entwickelt eine robuste, verteilte Software Transactional Memory (STM) Bibliothek für Haskell. Viele reale Anwendungen sind von Natur aus verteilt. Sie steuern entweder geografisch weit verteilte Ressourcen oder nutzen redundante Hardware-Komponenten, um Systemfehler zu verringern. STM ist eine Abstraktion, um gemeinsame Ressourcen in nebenläufigen Anwendungen zu synchronisieren. Sie hilft Verklemmungen zu verhindern und vereinfacht dadurch die Komposition des Programmcodes. Wir erweitern die STM-Abstraktion auf verteilte Systeme und präsentieren eine Implementierung, die effizient genug ist, um in weichen Echtzeit-Anwendungen genutzt zu werden. Weiterhin ist die implementierte Bibliothek selbst robust und bietet damit dem Anwendungsprogrammierer ein hohes Maß an Abstraktion, um Robustheit zu verwirklichen, was ihm diese, im Allgemeinen, komplexe Aufgabe deutlich erleichtert