Every now and then, a term or technology—even an established one—sneaks up and slips by. Take "transactions," for instance. Transactions are something we all do every day, but other than making sure the barrista forks over exact change, we don't give much thought to them. When it comes to software, however, there are lots of different kinds of transactions: Faircom's c-tree Server includes online transaction processing to guarantee ACID (atomicity, consistency, isolation, and durability); Microsoft's Transaction Server is a COM-based transaction processing system; Java sports a Transaction API; and Oracle's Berkeley DB is a transactional database engine, to mention a few.
Then there's Falcon (forge.mysql.com/wiki/Falcon), a transactional storage engine based on the Netfrastructure database engine, but extended and integrated into MySQL (and mentioned on page 20 of this issue by Jim Starkey, its designer). What's interesting about Falcon is that it is a transactional database engine designed from the ground up with multicore processors and threading in mind. It also supports Multi-Version Concurrency Control (MVCC), another 1980-era technology for concurrent access to databases.
These days, it seems that "transaction" and "concurrency" go hand-in-hand. Considering its stake in concurrency, it's no surprise that Intel has latched on to the concept of "software transactional memory" (STM), a technology that's been around since the early 1990s when Nir Shavit and Dan Touitou published their paper "Software Transactional Memory." Since then, STM has found its way into any number of environments, ranging from Smalltalk, C/C++, and C#, to Python, Perl, .NET, and Java, among others.
Clearly, from Intel's perspective, STM—or anything else that supports and promotes concurrency—is a good thing. Which is why the company added STM runtime libraries and transactional language construct extensions to its C++ compiler (softwarecommunity.intel.com/articles/eng/1460.htm). According to Intel, transactional memory simplifies parallel programming by supporting "atomic" and "isolated" execution of user-specified tasks. Intel goes on to say (and I paraphrase) that parallel programming traditionally used locks to synchronize concurrent access to shared data. But lock-based synchronization has known pitfalls: Using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory provides an alternative to locks as a general-purpose concurrency control mechanism. This alternate concurrency control mechanism avoids these pitfalls, thus easing parallel programming. (Locks, synchronization, and concurrency are topics that Herb Sutter tackles on page 57 of this issue.)
But transactional computing isn't just limited to databases and compilers, as Calum Grant points out in his article "Transactional Programming" on page 46 of this issue. Calum applies database concepts to C++ programming. And, as he says, "By copying the database approach, C++ can also implement transactions. It provides guarantees of atomic behavior, it can help in complex error-recovery situations, and allows smaller functions to be composed into larger transactions."
Transactional programming isn't limited to C++. Not only is it done with general-purpose languages, but also with special-purpose ones designed with transactions in mind. For instance, Atomos (tcc.stanford.edu/publications/tcc_pldi2006.pdf), a program language developed by Brian Carlstrom et al. at the Stanford University Computer Systems Lab, purports to be the first programming language with implicit transactions, strong atomicity, and a scalable multiprocessor implementation. According to its designers, Atomos is derived from Java, but replaces Java's synchronization and conditional waiting constructs with simpler transactional alternatives. Consequently, Atomos simplifies the writing of parallel programs utilizing transactional memory. The Atomos virtual machine uses violation handlers to recover from expected violations without necessarily rolling back. According to its developers, the performance benefits and simplicity of coding compared to Java demonstrate the value of programming with transactions.
The list could go on and on I suppose, but its time for me to head over to the coffee shop and initiate a transaction of my own.
Jonathan Erickson
Editor-in-Chief
