The Future(s) of Transactional Memory

Zeng, Jingna; Barreto, João; Haridi, Seif; Rodrigues, L.; Romano, Paolo

doi:10.1109/icpp.2016.57

Cited by 4 publications

(2 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Independently from our work, Zeng et al [67] developed Java Transactional Futures (JTFs). Here, an intratransactional conflict causes a future to roll back.…”

Section: Related Workmentioning

confidence: 99%

Chocola

Swalens

Koster

Meuter

2020

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

Programmers often combine different concurrency models in a single program, in each part of the program using the model that fits best. Many programming languages, such as Clojure, Scala, and Java, cater to this need by supporting different concurrency models. However, existing programming languages often combine concurrency models in an ad hoc way, and the semantics of the combinations are not always well defined. This article studies the combination of three concurrency models: futures, transactions, and actors. We show that a naive combination of these models invalidates the guarantees they normally provide, thereby breaking the assumptions of programmers. Hence, we present Chocola : a unified language of futures, transactions, and actors that maintains the guarantees of all three models wherever possible, even when they are combined. We describe and formalize the semantics of this language and prove the guarantees it provides. We also provide an implementation as an extension of Clojure and demonstrated that it can improve the performance of three benchmark applications for relatively little effort from the developer.

show abstract

“…Independently from our work, Zeng et al [67] developed Java Transactional Futures (JTFs). Here, an intratransactional conflict causes a future to roll back.…”

Section: Related Workmentioning

confidence: 99%

Chocola

Swalens

Koster

Meuter

2020

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

show abstract

“…To this end, HeTM exposes a conventional API, through which threads can start a new transaction, submit read and write operations and request the commit or abort of the transaction. Extending the proposed HeTM abstraction to support intra-transaction parallelism [2], [60] and non-transactional accesses [36] would be possible, but it is outside of the scope of this work.…”

Section: Defining the Hetm Abstractionmentioning

confidence: 99%

HeTM: Transactional Memory for Heterogeneous Systems

Castro

Romano

Ilić

et al. 2019

2019 28th International Conference on Parallel Architectures and Compilation Techniques (PACT)

Self Cite

View full text Add to dashboard Cite

Modern heterogeneous computing architectures, which couple multi-core CPUs with discrete many-core GPUs (or other specialized hardware accelerators), enable unprecedented peak performance and energy efficiency levels. Unfortunately, though, developing applications that can take full advantage of the potential of heterogeneous systems is a notoriously hard task. This work takes a step towards reducing the complexity of programming heterogeneous systems by introducing the abstraction of Heterogeneous Transactional Memory (HeTM). HeTM provides programmers with the illusion of a single memory region, shared among the CPUs and the (discrete) GPU(s) of a heterogeneous system, with support for atomic transactions. Besides introducing the abstract semantics and programming model of HeTM, we present the design and evaluation of a concrete implementation of the proposed abstraction, which we named Speculative HeTM (SHeTM). SHeTM makes use of a novel design that leverages on speculative techniques and aims at hiding the inherently large communication latency between CPUs and discrete GPUs and at minimizing inter-device synchronization overhead. SHeTM is based on a modular and extensible design that allows for easily integrating alternative TM implementations on the CPU's and GPU's sides, which allows the flexibility to adopt, on either side, the TM implementation (e.g., in hardware or software) that best fits the applications' workload and the architectural characteristics of the processing unit. We demonstrate the efficiency of the SHeTM via an extensive quantitative study based both on synthetic benchmarks and on a porting of a popular object caching system.

show abstract