Is transactional memory an oxymoron?

Abstract

Transactional memory (TM) was invented 15 years ago [1]. Recently, however, TM activity has exploded [2], as the proliferation of multicore chips has provoked researchers to revisit support for parallel programming. Since some regard me as a TM expert, most of my talk will summarize TM's goals and implementation options, primarily by developing a taxonomy and using Wisconsin LogTM [3, 4] as a case study. In particular, I will consider TM implementations via software, hardware, and hybrids, as well as important design choices, such as how to buffer TM writes and when to detect TM conflicts. I will conclude with forward-looking comments regarding TM and database transactions. In theory, the two concepts have many similarities. In practice, however, they differ substantially. First, today's TM exclusively targets concurrency, while database transactions seek reliability first. Second, TM implementations focus in operations with caches and memory, while database transactions deal more with the more substantial access gap between memory and disks. Finally, I will speculate on cross-fertilization opportunities between TM and database transactions. I will not provide answers here, in part because you are the database experts. Nevertheless, I hope to encourage us all to ask the right questions.