|go to week of Jun 26, 2016||26||27||28||29||30||1||2|
|go to week of Jul 3, 2016||3||4||5||6||7||8||9|
|go to week of Jul 10, 2016||10||11||12||13||14||15||16|
|go to week of Jul 17, 2016||17||18||19||20||21||22||23|
|go to week of Jul 24, 2016||24||25||26||27||28||29||30|
|go to week of Jul 31, 2016||31||1||2||3||4||5||6|
Software transactional memory (STM) is intended to make concurrent programs easier to design, implement, and reason about. STM is supported, either directly or through libraries, by an increasing number of languages and compilers, such as GNU C++, Clojure, Haskell, Java, Scala, and others. Perhaps inspired by databases, most STM synchronization and recovery mechanisms work by classifying operations as reads or writes. We argue that such an approach is unlikely to scale, especially for highly-contended "hot-spot" objects. As an alternative, we describe "transactional boosting", a technique for making highly-concurrent thread-safe data structures transactional. As long as the thread-safe
implementation satisfies certain regularity properties (informally, that every method has an inverse), we define a simple wrapper transformation that that concurrent transactions without inherent conflicts can synchronize at the same granularity as the original thread-safe implementation.