100 likes | 118 Views
This research from Microsoft in April 2005 delves into Transactional Memory as a promising abstraction for concurrent programming. It highlights how CMPs expose challenges, the software environment of this mechanism, and the limitations of simple "hardware" transactions. Examples showcase conflicting abstractions in code, nested transactions, and the impact on libraries and components. The study emphasizes the need to understand abstraction boundaries and the complexities involved in integrating Transactional Memory into existing environments.
E N D
It’s the Software, Stupid James Larus Microsoft Research April 2005
Transactional Memory • Promising abstraction for concurrent programming • CMPs bring problems to the forefront • Mechanism lives in software environment • simple “hardware” transactions may not provide appropriate semantics
Example 1: Conflicting Abstractions Code Transactional Memory
Example 1: Conflicting Abstractions Code GC TM TM
Example 2: Nested Transactions Code Libraries Components
What is abstraction boundary? Can library hide internal user of concurrency? Example 2: Nested Transactions Code Code Libraries Components Libraries
DB Example 3: IO Code TM
Summary • Not starting with a clean slate • TM must work within existing environment • changes to use TM will be large • unrealistic to change everything at once