Transactional Memory

Abstract

This chapter is devoted to software transactional memories (STM). This concept was first proposed by M. Herlihy and J. Moss (1993), and later refined by N. Shavit and D. Touitou (1997). The idea is to provide the designers of multiprocess programs with a language construct (namely, the notion of an atomic procedure called a transaction) that discharges them from the management of synchronization issues. More precisely, a programmer has to concentrate her efforts only on defining which parts of processes have to be executed atomically and not on the way atomicity is realized, this last issue being automatically handled by the underlying STM system.

This chapter, which is mainly on basic principles of algorithms implementing STM systems, assumes that the asynchronous processes are reliable (i.e., they never crash).

Appendices

Bibliographic Notes

• The concept of a transactional memory was introduced by M. Herlihy and J.E.B. Moss in 1993 [144]. It was then investigated in a software-only context by N. Shavit and D. Touitou [255].

• The reader will find introductory motivations for STM systems in [98, 134, 140, 195]. [124] is a book entirely devoted to the theory of transactional memory systems.

• Issues related to the specification of STM systems are addressed in [252].

• Conflict detection and contention management in the context of STM systems are addressed in several papers (e.g., [122, 249, 259]).

• The opacity consistency condition is due to R. Guerraoui and M. Kapałka [123]. This definition borrows and extends notions developed in the context of serializability theory [50, 51, 221, 222].

• Lots of algorithms implementing an STM system satisfying opacity have been proposed (e.g., [42, 61, 87, 141, 155, 156, 244, 245]).

• The TL2 system, based on a global logical clock and locks, presented in Sect. 10.3 is due to D. Dice, O. Shalev, and N. Shavit [87]. The presentation given in Sect.10.3 is a simplified version of TL2. An extension of TL2 where the centralized global clock is replaced by a distributed clock is presented in [42].

• The JVSTM system based on a multi-version technique presented in Sect. 10.4 is due to J. Cachopo and A. Rito-Silva [61]. As for TL2, the presentation given in Sect. 10.4 is a simplified version of JVSTM. More details and a proof will be found in [61].

• The management and maintenance of multi-version STM systems is addressed in [223].

• The virtual world consistency condition is due to D. Imbs, J.-R. Mendivil, and M. Raynal [153, 163]. A formal definition is presented in [163]. This consistency condition can be seen as a version of opacity weakened with notions of causality developed in shared memory systems or message-passing systems (e.g., in [17, 45, 136, 186, 202, 241, 251]).

• The STM system satisfying the virtual world consistency condition described in Sect. 10.5.2 is due to D. Imbs and M. Raynal [163]. A proof of correctness, based on a formal definition of virtual world consistency can be found in that paper.

• The notion of permissiveness of an STM system was introduced in [121]. Intuitively it requires that no transaction be aborted when there is no conflict. This notion was explored in [38, 82].

• A notion of a universal construction suited to STM systems is addressed in [83, 273].

Exercises and Problems

• 1. The logical clock used in the TL2 STM system is a global clock, which can constitute a bottleneck in heavy load.

  Modify the algorithms in order to replace this centralized clock by a vector clock-like distributed clock. Solution in [42].

• 2. Add to the simplified version of JVSTM a garbage collection mechanism that recycles the versions of the implementation registers which are too old to be used by transactions. Solution in [61].

• 3. Let us consider that, in the STM system presented in Sect. 10.5.2 (suited to virtual world consistency), the implementation registers $XX$ are MWMR regular registers instead of being atomic registers. Let us observe that, due to the locks used in $\mathsf{{try\_to\_commit}}_T()$ (locking at line 14, and unlocking at line 16 or 22), no two processes can write to the same register concurrently, from which it follows that all the writes into an implementation register $XX$ are sequential. Modify the algorithms described in Fig. 10.12 to obtain an STM system that works with such implementation registers. These modifications require only to:

  • Add the statement “if $predicate$ then $\mathsf{{return}}(abort,3)$ end if” between the two statements of line 22 where $predicate$ has to be appropriately defined, and

  • Modify the second predicate used at line 15.

  Prove then that these modifications guarantee that the implementation registers behave as if they were atomic.

  Solution in [163].