Semantics of transactional memory and automatic mutual exclusion

Abadi, Martı́n; Birrell, Andrew; Harris, Tim; Isard, Michael

doi:10.1145/1328438.1328449

Cited by 124 publications

(85 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…1,16 Whether or not one believes in transactions, it does seem likely that some combination of effect systems and/or ownership types will play an increasingly important role in concurrent programming languages, and these may contribute to the guarantees desirable for memory transactions.…”

Section: Resultsmentioning

confidence: 99%

Composable memory transactions

et al. 2008

Self Cite

View full text Add to dashboard Cite

Writing concurrent programs is notoriously difficult and is of increasing practical importance. A particular source of concern is that even correctly implemented concurrency abstractions cannot be composed together to form larger abstractions. In this paper we present a concurrency model, based on transactional memory, that offers far richer composition. All the usual benefits of transactional memory are present (e.g., freedom from low-level deadlock), but in addition we describe modular forms of blocking and choice that were inaccessible in earlier work. intRoDuctionThe free lunch is over. 25 We have been used to the idea that our programs will go faster when we buy a next-generation processor, but that time has passed. While that nextgeneration chip will have more CPUs, each individual CPU will be no faster than the previous year's model. If we want our programs to run faster, we must learn to write parallel programs.Writing parallel programs is notoriously tricky. Mainstream lock-based abstractions are difficult to use and they make it hard to design computer systems that are reliable and scalable. Furthermore, systems built using locks are difficult to compose without knowing about their internals.To address some of these difficulties, several researchers (including ourselves) have proposed building programming language features over software transactional memory (STM), which can perform groups of memory operations atomically. 23 Using transactional memory instead of locks brings well-known advantages: freedom from deadlock and priority inversion, automatic roll-back on exceptions or timeouts, and freedom from the tension between lock granularity and concurrency.Early work on software transactional memory suffered several shortcomings. Firstly, it did not prevent transactional code from bypassing the STM interface and accessing data directly at the same time as it is being accessed within a transaction. Such conflicts can go undetected and prevent transactions executing atomically. Furthermore, early STM systems did not provide a convincing story for building operations that may block-for example, a shared work-queue supporting operations that wait if the queue becomes empty.Our work on STM-Haskell set out to address these problems. In particular, our original paper makes the following contributions:

show abstract

Section: Resultsmentioning

confidence: 99%

Composable memory transactions

et al. 2008

Self Cite

View full text Add to dashboard Cite

show abstract

“…In contrast to privatization, publication [20,1] is less studied but also impacts STM correctness as illustrated in Figure 1. While privatization violations occur because transactional write operations can be delayed by an STM, publication violations occur because transactional read operations may be speculated early.…”

Section: Maintaining Orderingmentioning

confidence: 99%

“…In this model, transactions are strictly more restrictive than locks and, thus, provide programmers with sufficiently strong guarantees. However, strong atomicity typically requires either specialized hardware support [23,4,11,21] not available on existing systems, a sophisticated type system [13,22,1] that may not be easily integrated with languages such as Java or C++, or runtime barriers on non-transactional reads or writes [24] that can incur substantial cost on programs that do not use transactions.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Practical weak-atomicity semantics for java stm

Menon

Balensiefer

Shpeisman

et al. 2008

Proceedings of the Twentieth Annual Symposium on Parallelism in Algorithms and Architectures

114

View full text Add to dashboard Cite

As memory transactions have been proposed as a languagelevel replacement for locks, there is growing need for welldefined semantics. In contrast to database transactions, transaction memory (TM) semantics are complicated by the fact that programs may access the same memory locations both inside and outside transactions. Strongly atomic semantics, where non-transactional accesses are treated as implicit single-operation transactions, remain difficult to provide without specialized hardware support or significant performance overhead. As an alternative, many in the community have informally proposed that a single global lock semantics [18,10], where transaction semantics are mapped to those of regions protected by a single global lock, provide an intuitive and efficiently implementable model for programmers.In this paper, we explore the implementation and performance implications of single global lock semantics in a weakly atomic STM from the perspective of Java, and we discuss why even recent STM implementations fall short of these semantics. We describe a new weakly atomic Java STM implementation that provides single global lock semantics while permitting concurrent execution, but we show that this comes at a significant performance cost. We also propose and implement various alternative semantics that loosen single lock requirements while still providing strong guarantees. We compare our new implementations to previous ones, including a strongly atomic STM. [24]

show abstract

“…The vision of pioneers is finally being materialized in the form of novel TM-enabled multicores like Intel Haswell [5] and IBM Blue Gene [6]. The emergence of these brand new TM-enabled multicores has been preceded with an intensive theoretical research on TM correctness [3], [4], liveness [7], and programming language level semantics [8], [9], [10], which seems to be culminating in what would be a theoretical foundation of contemporary TM-based systems. Looking from current prospective it seems that the main reason for the TM success are the two main advantages of TM over traditional locks.…”

Section: Introductionmentioning

confidence: 99%

Conflict types and probabilities in stochastic TM-programs

Popović

Basicevic

2014

2014 4th IEEE International Conference on Information Science and Technology

View full text Add to dashboard Cite

Transactional Memory (TM) is an attractive concurrency control mechanism that should deliver much better performance than locks in case when transaction conflicts are rare. But, if the probability of conflicts is high, TM program performance may be very poor. Therefore, when engineering mission critical systems, we need to be able to calculate conflict probabilities. In this paper we study a class of stochastic TM programs for processing groups of transactions on a set of shared t-variables, e.g. bank accounts. Individual transactions are selecting variables they are operating on uniformly at random. We identify and define various types of conflicts among transactions that may arise in such circumstances. We also show how to calculate probabilities of various types of conflicts on some simple examples of groups of transactions sharing one or two t-variables. Our work is still in progress, but the results shown here are affirmative for the approach we use, and they stimulate further research towards more general analysis of this class of TM programs.

show abstract

Semantics of transactional memory and automatic mutual exclusion

Cited by 124 publications

References 26 publications

Composable memory transactions

Composable memory transactions

Practical weak-atomicity semantics for java stm

Conflict types and probabilities in stochastic TM-programs

Contact Info

Product

Resources

About