Transactional Memory Should Be an Implementation Technique, Not a Programming Interface
Keyword(s): transactional memory, locks
Abstract: Transactional memory is often advocated as an easier- to-use replacement or 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.
Additional Publication Information:
External Posting Date: February 21, 2009 [Fulltext]. Approved for External Publication
Internal Posting Date: February 21, 2009 [Fulltext]