Transactional memory
In computer science and engineering, transactional memory attempts to simplify concurrent 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 |
Motivation [edit]
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_account, to_account, amount): with transaction(): from_account -= amount to_account += 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.
Hardware versus software implementation [edit]
Hardware transactional memory systems may comprise modifications in processors, cache and bus protocol to support transactions.[1][2][3][4][5] 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.
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).
Implementations [edit]
Hardware [edit]
- Rock processor (canceled by Oracle)
- BlueGene/Q processor from IBM (Sequoia supercomputer)[7]
- IBM zEnterprise EC12, the first commercial server to include transactional memory processor instructions
- Transactional Synchronization Extensions specified by Intel first for Haswell processor
Software [edit]
- Vega 2 from Azul Systems[8]
- STM Monad in the Glasgow Haskell Compiler
- Refs in Clojure
See also [edit]
References [edit]
- ^ Herlihy, Maurice; Moss, J. Eliot B. (1993). "Transactional memory: Architectural support for lock-free data structures" (PDF). 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–13. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1310767.
- ^ "Unbounded transactional memory".
- ^ "LogTM: Log-based transactional memory" (PDF). WISC.
- ^ "The ATOMOΣ Transactional Programming Language" (PDF). Stanford.
- ^ "IBM plants transactional memory in CPU". EE Times.
- ^ Java on a 1000 Cores – Tales of Hardware/Software CoDesign on YouTube
Further reading [edit]
- Larus, James R.; Rajwar, Ravi (2006), Transactional Memory, Synthesis Lectures on Computer Architecture 1 (1), Morgan & Claypool, pp. 1–226, doi:10.2200/S00070ED1V01Y200611CAC002
- Harris, Tim; Larus, James R.; Rajwar, Ravi (December 2010), Transactional Memory, 2nd edition, Synthesis Lectures on Computer Architecture 5 (1), Morgan & Claypool, pp. 1–263, doi:10.2200/S00272ED1V01Y201006CAC011
- McKenney, Paul E.; Michael, Maged M.; Triplett, Josh; Walpole, Jonathan (July 2010). "Why the grass may not be greener on the other side: a comparison of locking vs. transactional memory". SIGOPS Oper. Syst. Rev. (New York, NY, USA: ACM) 44 (3): 93–101. doi:10.1145/1842733.1842749. ISSN 0163-5980.
External links [edit]
- Transactional Memory Online: Categorized bibliography about transactional memory
