Composable memory transactions

By T. Harris, Simon David Marlow, Simon L. Peyton Jones, Maurice Herlihy. ACM SIGPLAN Symposium on Principles & Practice of Parallel Programming, 2005

836 citations recorded by the source corpus.

Subfields: Computer Networks and Communications, Experimental and Cognitive Psychology, Hardware and Architecture

View Paper: https://www.semanticscholar.org/paper/8a03fe7092f8284d999fb18bbe8bf84a37681d28

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Computer Networks and Communications

In Experimental and Cognitive Psychology

In Hardware and Architecture

Citations in the corpus

Alpaca: intermittent execution without checkpoints (2017, background): “Transactions [Gray and Reuter 1992] and, in particular, transactional memory [Hammond et al. 2004; Harris et al. 2005; Herlihy and Moss 1993; Shavit and Touitou 1995] (TM) systems are also related to Alpaca.”
Parallel Programmability and the Chapel Language (2007, background): “Atomic sections have been of recent interest to the software transactional memory community due to their intuitiveness and ability to replace explicit lock management in user code [33, 32, 1, 26].”
A history of Haskell: being lazy with class (2007, background): “…memory had a ten-year history in imperative settings, when Harris,Marlow, Herlilhy and Peyton Jones transposed it into the Haskell setting they immediately stumbled on two powerful new composition operators (retry and orElse) that had lain hidden until then (see (Harris et al., 2005) for details).”
LogTM-SE: Decoupling Hardware Transactional Memory from Caches (2007, background): “In addition, some proposed language extensions for transactional memory, such as retry and orelse, depend on arbitrarily deep nesting [13].”
Scala Actors: Unifying thread-based and event-based programming (2009, background): “We also note that alternatives such as transactional memory [25,26], even though a clear improvement over locks, do not provide seamless support for I/O operations as of yet.”
Mnemosyne: lightweight persistent memory (2011, background): “Recent work on transactional memory focuses on the concurrency of transactions, through automatic detection of conflicts, rather than on durability [30, 29].”
Transactional Memory, 2nd edition (2010, methodology): “[136] introduced the retry statement to coordinate atomic blocks in STM-Haskell, Ringenburg and Grossman introduced an analogous statement for a variant of ML [266], and AdlTabatabai et al.”
The problem with threads (2006, background): “Transactions eliminate unintended deadlocks, but despite recent extensions for composability [26], remain a highly nondeterministic interaction mechanism.”
In-Memory Big Data Management and Processing: A Survey (2015, background): “STM Much Atomic Operation Large TinySTM [159], Clojure [160], Haskell [161] HTM No or Little Cache, Bus Protocol Small Intel TSX [162], AMD ASF [163]”
Transactional boosting: a methodology for highly-concurrent transactional objects (2008, methodology): “We are grateful to Tim Harris for pointing out that transactional boosting can be extended to support the retry () construct for conditional synchronization from STMHaskell [9], monitoring lock releases to reschedule retried transactions.”
McRT-STM: a high performance software transactional memory system for a multi-core runtime (2006, methodology): “We present a detailed performance analysis of various STM design tradeoffs such as pessimistic versus optimistic concurrency, undo logging versus write buffering, and cache line based versus object based conflict detection.”
Learning from mistakes: a comprehensive study on real world concurrency bug characteristics (2008, neutral): “Recently, some TM designs [5, 17] are equipped with rich semantics (such as watch/retry, retry/orElse) and can help enforce some of the above synchronization intentions.”