Transactional memory
Transactional memory attempts to simplify parallel programming by allowing a group of load and store instructions to execute in an atomic way. It is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing.
Contents |
[edit] Hardware vs. software transactional implementations
Hardware transactional memory systems may comprise modifications in processors, cache and bus protocol to support transactions.[1][2][3][4][5]
Software transactional memory provides transactional memory semantics in a software runtime library or the programming language,[6] and requires minimal hardware support (typically an atomic compare and swap operation, or equivalent).
Load-link/store-conditional (LL/SC) offered by many RISC processors can be viewed as the most basic transactional memory support. However, LL/SC usually operates on data that is the size of a native machine word.
[edit] Motivation
The motivation of transactional memory lies in the programming interface of parallel programs. The goal of a transactional memory system is to transparently support the definition of regions of code that are considered a transaction, that is, that have atomicity, consistency and isolation requirements. Transactional memory allows writing code like this example:
def transfer_money(from, to, amount): transaction: from = from - amount to = to + amount
In the code, the block defined by "transaction" has the atomicity, consistency and isolation guarantees and the underlying transactional memory implementation must assure those guarantees transparently.
[edit] Implementations
- Rock processor (canceled by Oracle)
- Vega 2 from Azul Systems[7]
- BlueGene/Q processor from IBM (Sequoia supercomputer)[8]
- Transactional Synchronization Extensions specified by Intel first for Haswell processor
[edit] References
- ^ Herlihy, Maurice; Moss, J. Eliot B. (1993). "Transactional memory: Architectural support for lock-free data structures". Proceedings of the 20th International Symposium on Computer Architecture (ISCA). pp. 289–300. http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf.
- ^ Multiple Reservations and the Oklahoma Update. doi:10.1109/88.260295.
- ^ Hammond, L.; Wong, V.; Chen, M.; Carlstrom, B.D.; Davis, J.D.; Hertzberg, B.; Prabhu, M.K.; Honggo Wijaya; Kozyrakis, C.; Olukotun, K. (2004). "Transactional memory coherence and consistency". Proceedings of the 31st annual International Symposium on Computer Architecture (ISCA). pp. 102–113. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1310767.
- ^ "Unbounded transactional memory". http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1385954.
- ^ "LogTM: Log-based transactional memory". http://www.cs.wisc.edu/multifacet/papers/hpca06_logtm.pdf.
- ^ "The ATOMOΣ Transactional Programming Language". http://tcc.stanford.edu/publications/tcc_pldi2006.pdf.
- ^ Java on a 1000 Cores - Tales of Hardware / Software CoDesign on YouTube
- ^ "IBM plants transactional memory in CPU". http://www.eetimes.com/electronics-news/4218914/IBM-plants-transactional-memory-in-CPU.
- Larus, J.R. and Rajwar, R. Transactional Memory, Morgan & Claypool, 2006.
[edit] External links
- Transactional Memory Online: Categorized bibliography about transactional memory
