BT

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

.NET 4 Beta 1 Now Supports Software Transactional Memory

Bookmarks

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.

Rate this Article

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

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

Community comments

  • ...and then what happens?

    by Jonathan Allen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: ...and then what happens?

    by Patrick Huizinga /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

    by Jonathan Allen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

    by Peter Veentjer /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.