Transactions, Now and for the Future

Abstract

With the advent of desktop multiprocessors, and even chip multiprocessors, concurrency is increasingly recognized as the next major trend in programming. Unfortunately, the current state of the art in concurrent programming is woefully inadequate: The dominant abstraction for communication--shared memory mediated by locks--is the equivalent of assembly code for concurrent programs: it shields you from the bare machine but does not provide an adequate means for further abstraction. As a result, large concurrent programs are fragile (and almost always incorrect), stifling innovation and threatening reliability. As the world grows increasingly dependent on interconnected computing, we can ill afford such programs.

Transactions--atomic blocks of code--have been proposed as a mechanism for structuring large-scale concurrent programs. They have been used successfully for decades in database systems, and there is renewed interest in providing "lightweight transactions" at other levels of the system: at the language level, and even in hardware. However, there are fundamental challenges, for both semantics and implementation, to making lightweight transactions available and accessible to programmers in general. Our group at Sun (and many others) has been exploring and devising mechanisms for supporting transactions, both at the language level and in hardware. I will talk about the benefits of transactional programming, the challenges in making it feasible, and some work that we are doing to address these challenges.