Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News .NET 4 Beta 1 Now Supports Software Transactional Memory

.NET 4 Beta 1 Now Supports Software Transactional Memory

Leia em Português

This item in japanese

Microsoft has released a new version of .NET 4.0 Beta 1, one that incorporates STM.NET, the Software Transactional Memory. STM is an alternative mechanism to lock-based synchronization used to control the concurrent access to shared memory.

Microsoft defines STM.NET as:

Software Transactional Memory (STM.NET) is a mechanism for efficient isolation of shared state.  The programmer demarcates a region of code as operating within a transaction that is “atomic” and “isolated” from other transacted code running concurrently.

Transactional memory is considered a promising technology by the academic community and is repeatedly brought up as a welcome technology for the upcoming wave of applications which scale on modern multi-core hardware. The goal is to be able to exploit concurrency by using components written by experts and consumed by application programmers who can then compose together these components using STM. Transactional memory provides an easy-to-use mechanism to do this safely.

STM uses an optimistic approach to accessing a shared piece of memory. Instead of blocking the writer until it is safe to perform the changes to the shared data, the thread accesses and edits the shared data while logging each read and write it performs. In the end, it verifies if another thread has happened to access the shared data in the same time. If not, a commit is executed and the changes are made permanent. If another thread has accessed the data, the transaction is aborted, and all changes are rolled back.

STM.NET uses Atomic.Do() to mark statements that are to be executed as one transaction:

Atomic.Do(()=> {



As with any other locking mechanism, STM induces a performance penalty because it has to maintain the read/write log and due to the time spent during committing phase. Some consider that penalty is compensated by the conceptual benefits which make STM easier to use than fine-grain locking. In a study called Is Transactional Programming Actually Easier?, Christopher J. Rossbach, Owen S. Hofmann, and Emmett Witchel from University of Texas at Austin analyze the learning and the development process using STM compared with other types of locking, remarking that:

On average, transactional memory required more development time than coarse locks, but less than required for fine-grain locks and condition synchronization.

… We found that coarse locks and transactions required less time than fine-grain locks on the more complex two-lane assignments. This echoes the promise of transactions, removing the coding and debugging complexity of fine-grain locking and lock ordering when more than one lock is required.

The study concludes:

This paper offers evidence that transactional programming really is less error-prone than high-performance locking, even if newbie programmers have some trouble understanding transactions. Students subjective evaluation showed that they found transactional memory slightly harder to use than coarse locks, and easier to use than fine-grain locks and condition synchronization. However, analysis of synchronization error rates in students’ code yields a more dramatic result, showing that for similar programming tasks, transactions are considerably easier to get correct than locks.

Requirements: Visual Studio 2008, Windows Installer 3.1 or later, Internet Explorer 5.01 or later. STM.NET is currently available only for C#.

Resources: NET 4.0 Beta 1 with STM.NET, STM Programming Guide, STM: Samples, Documentation, and Configuration files.

Rate this Article