Transactional memory: architectural support for lock-free data structures
ISCA '93 Proceedings of the 20th annual international symposium on computer architecture
Proceedings of the fourteenth annual ACM symposium on Principles of distributed computing
Weak ordering—a new definition
ISCA '90 Proceedings of the 17th annual international symposium on Computer Architecture
Reference Manual for the ADA Programming Language
Reference Manual for the ADA Programming Language
Speculative lock elision: enabling highly concurrent multithreaded execution
Proceedings of the 34th annual ACM/IEEE international symposium on Microarchitecture
Proceedings of the 32nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Threads cannot be implemented as a library
Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation
Composable memory transactions
Proceedings of the tenth ACM SIGPLAN symposium on Principles and practice of parallel programming
Autolocker: synchronization inference for atomic sections
Conference record of the 33rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Compiler and runtime support for efficient software transactional memory
Proceedings of the 2006 ACM SIGPLAN conference on Programming language design and implementation
Computer
What do high-level memory models mean for transactions?
Proceedings of the 2006 workshop on Memory system performance and correctness
Proceedings of the 34th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Reordering constraints for pthread-style locks
Proceedings of the 12th ACM SIGPLAN symposium on Principles and practice of parallel programming
How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs
IEEE Transactions on Computers
Foundations of the C++ concurrency memory model
Proceedings of the 2008 ACM SIGPLAN conference on Programming language design and implementation
Inferring locks for atomic sections
Proceedings of the 2008 ACM SIGPLAN conference on Programming language design and implementation
Against lock-based semantics for transactional memory
Proceedings of the twentieth annual symposium on Parallelism in algorithms and architectures
Single global lock semantics in a weakly atomic STM
ACM SIGPLAN Notices
Design and implementation of transactional constructs for C/C++
Proceedings of the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
Language constructs for transactional memory
Proceedings of the 36th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Towards transactional memory semantics for C++
Proceedings of the twenty-first annual symposium on Parallelism in algorithms and architectures
Composable, nestable, pessimistic atomic statements
Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications
Synchronization cannot be implemented as a library
Proceedings of the 2012 ACM conference on High integrity language technology
Lock-free protected types for real-time ada
ACM SIGAda Ada Letters
A survey of support for structured communication in concurrency control models
Journal of Parallel and Distributed Computing
| Hi-index | 0.00 |
Transactional memory is often advocated as an easier to use replacement for locks that avoids any possibility of deadlock. Recently, as more care has been exercised in precisely specifying its semantics, a number of researchers have observed that probably the most attractive semantics for transactional memory systems is based on "single global lock atomicity", i.e. on the semantics of a single global lock. We argue that this should be taken one step further: The synchronization operations seen by the programmer should really just be locks, possibly with some syntactic sugar for easier programming with a single global lock. Use as a deadlock-free lock replacement does not require any rollback primitive, or any other constructs that expose properties of the implementation. And it appears that such extensions add considerable complexity. Instead, the implementation should strive to optimize coarse-grain locks, for example by implementing them using transactional techniques.