.NET 4 Beta 1 Now Supports Software Transactional Memory

Posted by Abel Avram on Jul 28, 2009

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Transactions Processing ,

.NET Framework ,

.NET

Tags

Transactions ,

.NET Framework 4.0

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

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

1. Back to top

   ...and then what happens?

   by Jonathan Allen

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

   Reply

2. Back to top

   Re: ...and then what happens?

   by Patrick Huizinga

   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.

   Reply

3. Back to top

   Re: ...and then what happens?

   by Jonathan Allen

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

   Reply

4. Back to top

   Re: ...and then what happens?

   by Peter Veentjer

   That is correct. Depending on the implementation of the STM, you can also do an orelse:
   
   {
   stack1.pop();
   }orelse{
   stack2.pop();
   }

   Reply

• Older >