Transactional memory coherence and consistency

Hammond, Lance; Wong, Vicky; Chen, M.; Carlstrom, Brian D.; Davis, John D.; Hertzberg, Ben; Prabhu, Manohar K.; Wijaya, Honggo; Kozyrakis, Christos; Olukotum, K.

doi:10.1109/isca.2004.1310767

Cited by 339 publications

(424 citation statements)

References 37 publications

Supporting

Mentioning

390

Contrasting

Order By: Relevance

“…Thus, upon detecting mispeculation, most TLS schemes abort the task that caused the violation and all later speculative tasks [25,28,61,66,68]. TCC [29] and Bulk [11] are the exception: they do not forward data and only abort later readers when the earlier writer commits.…”

Section: Background On Hw Support For Speculative Parallelismmentioning

confidence: 99%

“…By contrast, most TLS systems use lazy versioning (buffering speculative data in caches) or more expensive multiversioning [11,25,28,29,56,60,61,66,68,69] to limit the cost of aborts. Some early TLS schemes are eager [25,80], and they still suffer from the limitations discussed in Sec.…”

Section: Speculative Execution and Versioningmentioning

confidence: 99%

“…Several TLS schemes expose timestamps to software for different purposes, such as letting the compiler schedule loop iterations in Stampede [68], speculating across barriers in TCC [29], and supporting out-of-order spawn of speculative function calls in Renau et al [61]. These schemes work well for their intended purposes, but cannot queue or buffer tasks with arbitrary timestampsthey can only spawn new work if there is a free hardware context.…”

Section: Additional Related Workmentioning

confidence: 99%

See 2 more Smart Citations

A scalable architecture for ordered parallelism

Jeffrey¹,

Subramanian²,

Yan³

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

We present Swarm, a novel architecture that exploits ordered irregular parallelism, which is abundant but hard to mine with current software and hardware techniques. In this architecture, programs consist of short tasks with programmer-specified timestamps. Swarm executes tasks speculatively and out of order, and efficiently speculates thousands of tasks ahead of the earliest active task to uncover ordered parallelism. Swarm builds on prior TLS and HTM schemes, and contributes several new techniques that allow it to scale to large core counts and speculation windows, including a new execution model, speculation-aware hardware task management, selective aborts, and scalable ordered commits.We evaluate Swarm on graph analytics, simulation, and database benchmarks. At 64 cores, Swarm achieves 51-122× speedups over a single-core system, and outperforms software-only parallel algorithms by 3-18×.

show abstract

Section: Background On Hw Support For Speculative Parallelismmentioning

confidence: 99%

Section: Speculative Execution and Versioningmentioning

confidence: 99%

Section: Additional Related Workmentioning

confidence: 99%

See 1 more Smart Citation

A scalable architecture for ordered parallelism

Jeffrey¹,

Subramanian²,

Yan³

et al. 2015

Proceedings of the 48th International Symposium on Microarchitecture

View full text Add to dashboard Cite

show abstract

“…Several proposals [1,7,12,20] seek to leverage cache coherence protocols to achieve lightweight hardware transactions. However, these hardware TMs generally fix the conflict detection policy at design time, with eager read-write conflict detection more common than lazy [20].…”

Section: Related Workmentioning

confidence: 99%

Conflict Detection and Validation Strategies for Software Transactional Memory

Spear

Marathe

Scherer

et al. 2006

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. In a software transactional memory (STM) system, conflict detection is the problem of determining when two transactions cannot both safely commit. Validation is the related problem of ensuring that a transaction never views inconsistent data, which might potentially cause a doomed transaction to exhibit irreversible, externally visible side effects. Existing mechanisms for conflict detection vary greatly in their degree of speculation and their relative treatment of read-write and write-write conflicts. Validation, for its part, appears to be a dominant factor-perhaps the dominant factor-in the cost of complex transactions.We present the most comprehensive study to date of conflict detection strategies, characterizing the tradeoffs among them and identifying the ones that perform the best for various types of workload. In the process we introduce a lightweight heuristic mechanism-the global commit counter-that can greatly reduce the cost of validation and of single-threaded execution. The heuristic also allows us to experiment with mixed invalidation, a more opportunistic interleaving of reading and writing transactions. Experimental results on a 16-processor SunFire machine running our RSTM system indicate that the choice of conflict detection strategy can have a dramatic impact on performance, and that the best choice is workload dependent. In workloads whose transactions rarely conflict, the commit counter does little to help (and can even hurt) performance. For less scalable applications, however-those in which STM performance has traditionally been most problematic-it can improve transaction throughput many fold.

show abstract

“…We study whether this is also the case for transactional memories, where we focus on different approaches to transactional memory implementation. Specifically, we consider Transactional Memory Coherence and Consistency (TCC) [9], Unbounded Transactional Memory (UTM) [2], and a general scheme for conflict detection and arbitration [17]. Some of these implementations turn out to be secure with respect to the policy associated to arbitrary access control tables, others turn out to be insecure even for the very simple information flow policy involving two agents H and L with information flow from H to L prohibited.…”

Section: Introductionmentioning

confidence: 99%

Access Control and Information Flow in Transactional Memory

Cohen

Meyden

Zuck

2009

Formal Aspects in Security and Trust

View full text Add to dashboard Cite

Abstract. The paper considers the addition of access control to a number of transactional memory implementations, and studies its impact on the information flow security of such systems. Even after the imposition of access control, the Unbounded Transactional Memory due to Ananian et al, and most instances of a general scheme for transactional conflict detection and arbitration due to Scott, are shown to be insecure. This result applies even for a very simple policy prohibiting information flow from a high to a low security domain. The source of the insecurity is identified as the ability of agents to cause aborts of other agents' transactions. A generic implementation is defined, parameterized by a "may-abort" relation that defines which agents may cause aborts of other agents' transactions. This implementation is shown to be secure with respect to an intransitive information flow policy consistent with the access control table and "may-abort" relation. Using this result, Transactional Memory Coherence and Consistency, an implementation due to Hammond et al, is shown to be secure with respect to intransitive information flow policies. Moreover, it is shown how to modify Scott's arbitration policies using the may-abort relation, yielding a class of secure implementations closely related to Scott's scheme.

show abstract

Transactional memory coherence and consistency

Cited by 339 publications

References 37 publications

A scalable architecture for ordered parallelism

A scalable architecture for ordered parallelism

Conflict Detection and Validation Strategies for Software Transactional Memory

Access Control and Information Flow in Transactional Memory

Contact Info

Product

Resources

About