# .NET 4 Beta 1 Now Supports Software Transactional Memory

| by Abel Avram 5 Followers on Jul 28, 2009. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

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(()=> {   <statememts>});

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#.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

...and then what happens?

Ok, so what the heck am I supposed to do when the transaction rolls back?

Re: ...and then what happens?

STM will then automatically retry the transaction.
You won't have to do anything.

In fact when you have this piece of code:
Atomic.Do(() => {  if (ViolatesPrecondition(value))    Atomic.Retry();  ...;});

it will even wait for value to change before it does the actual retry.

At least that's what understood from the STM Programming Guide resource referenced at the end of this article.

Re: ...and then what happens?

Ok, so long as I don't have to worry about being a deadlock victim like I do with T-SQL programming.

Re: ...and then what happens?

That is correct. Depending on the implementation of the STM, you can also do an orelse:

{
stack1.pop();
}orelse{
stack2.pop();
}
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.