Loading [MathJax]/extensions/MathZoom.js
The Velox Transactional Memory Stack | IEEE Journals & Magazine | IEEE Xplore

Abstract:

The adoption of multi- and many-core architectures for mainstream computing undoubtedly brings profound changes in the way software is developed. In particular, the use o...Show More

Abstract:

The adoption of multi- and many-core architectures for mainstream computing undoubtedly brings profound changes in the way software is developed. In particular, the use of fine grained locking as the multi-core programmer's coordination methodology is considered by more and more experts as a dead-end. The transactional memory (TM) programming paradigm is a strong contender to become the approach of choice for replacing locks and implementing atomic operations in concurrent programming. Combining sequences of concurrent operations into atomic transactions allows a great reduction in the complexity of both programming and verification, by making parts of the code appear to execute sequentially without the need to program using fine-grained locking. Transactions remove from the programmer the burden of figuring out the interaction among concurrent operations that happen to conflict when accessing the same locations in memory. The EU-funded FP7 VELOX project designs, implements and evaluates an integrated TM stack, spanning from programming language to the hardware support, and including runtime and libraries, compilers, and application environments. This paper presents an overview of the VELOX TM stack and its associated challenges and contributions.
Published in: IEEE Micro ( Volume: 30, Issue: 5, Sept.-Oct. 2010)
Page(s): 76 - 87
Date of Publication: 09 September 2010

ISSN Information:


A New Paradigm for Concurrent Programming

Transactions let developers indicate that code sections must execute atomically-that is, as if they were run in isolation from the rest of the code. Transactional memory is a speculative execution mechanism in which accesses to shared objects can run simultaneously. In case of conflicting accesses, detected at runtime, one or several transactions might have to roll back and restart their execution. In other words, transactions execute optimistically in parallel and, as long as conflicts are rare, the performance gains resulting from the higher concurrency dominate the overheads introduced by transactional execution.

Contact IEEE to Subscribe

References

References is not available for this document.