STM.NET on DevLabs

Today we made available STM.NET on MSDN DevLabs.  STM.NET is an experimental enhanced version of .NET Framework 4 Beta 1 that enables software transactional memory for C# programmers.


Transactional memory is a technology that frees developers from worrying about the mechanics of fine-grained locking and synchronization in multithreaded applications by providing transactional semantics for reading and writing to memory.  It enables developers to focus on application logic instead of the details of memory I/O when building multi-core and many-core programs.


Building Transactions

STM.NET makes it easy to declare a region of code as atomic. Simply write a function or lambda containing the code that you’d like to transact and pass it to the Atomic.Do delegate.  Just like SQL code in a database transaction, this block of code will run as if isolated from other transacted blocks and either it completes successfully or rolls back the complete transaction if there is an error, all without you having to explicitly lock anything.


How Does it Work?

The .NET Framework’s just-in-time compiler rewrites the code within an atomic block to use transactional memory.  As a result, a significant amount of .NET code works without changes, including code that uses locks.  STM.NET also provides integration with System.Transactions so you can coordinate your atomic memory operations with existing transactional resource managers like MSMQ.


One of the best aspects of STM.NET is its integration with Visual Studio tooling.  STM.NET works with the Visual Studio 2008 debugger to allow you to see the values of transacted variables as they appear while running inside the Atomic.Do delegate as well as their values as they appear outside.


STM.NET is available for download today.  Share your thoughts and experiences on the project’s forum, and read more about STM.NET on the STM.NET Team Blog. 




Comments (9)

  1. Sam says:

    This is an awesome feature. Hopefully it works as expected. Will check it out soon! .NET rocks!

  2. Jason says:

    This is exciting, I can’t wait to check it out!

  3. Jesper says:

    You guys keep telling us that VB and C# are equals.

    Yet once again we have to vitness another C#-only feature release.


  4. Louis de Klerk says:

    Why only C#?

    Surely the legions of VB.NET developers also need this?

    I for one can think of many really compelling uses for this technology – and I (and my team) prefers VB.NET.

    At least make a statement that clarifies the absence of VB.NET, if only to say it will be in the next version, or a service pack, etc.

  5. danieldsmith says:

    @Jesper – then don’t use such a freakish language and upgrade to C# and avoid being left behind all the time!  Only kidding (mostly!) – I’m actually quite jealous VB seems to be getting initialisers for auto properties, which is something C# devs have been crying out for for ages:

    As for STM.NET this does look interesting.  I see it requires a modified CLR though.  The only thing I’m worried about is – are there any performance penalties for existing apps that don’t make use of the new features?

  6. Ian Ringrose says:


    If this works well, I will not longer have to consider multi threaded programming to be more often part of the problem then the solution.   (I am assume that STM will be in ALL editions of developer studio and that it will be make to work with ALL ORM including NHibernate)

    For example a web system I am working on today (that was written a few years ago) duplicates a lot of a data in the user’s sessions objects, as we could not face having to debug locking problem.  With STM we could have shared the data between all users and saved many MB per logged on user.

    Now can we have support for asserting that objects/methods are immutable in Code Contracts and standard versioned data collections in the BCL to complete the picture.

  7. TheCPUWizard says:


    This is GREAT and I am looking forward to hearing a commitment on this functionallity being made available in a supported manner.

    The items emerging from Dev Div have simply been fantastic and everyone on the team deserves as big CONGRATULATIONS….keep up the good work.


    As to Ian’s comment.. I have long held the viewpoint that the single biggests barrier to effective parallel execution is changing the developers mindset, and not specific technologies.

    From a you age people are taught to think things out "step by step" (a sequential flow) rather than thinking "get all of your friends together and figure out how many things you can do as the same time to accomplish the final goal in the minimum time".

    David V. Corbin

    Microsoft MVP

    President / Chief Architect

    Dynamic Concepts Development Corp.

    New York, NY

  8. DGroff says:

    I will try to address some of these questions and comments here but I encourage you to have a discussion of these issues on the STM.NET forum (see below).

    DanielSmith: we made a large effort to make STM pay-for-play — so non STM code will not pay a measurable penalty.  But, this release is experimental, so we haven’t spent a huge effort tuning for performance.

    Jesper and Louis: I would love to hear about your VB requirements for STM.

    Why did we omit support for VB?  The truth is that with a small team, we had to make hard decisions and limit the scope of our release.  We did not have the engineering resources to adequately cover all languages — so we focused on one.  The goal was to create a STM framework that could, in practice, work for all languages but for this limited experimental release our first target is C#.  

    Please feel free to create a thread in the STM forum to discuss your VB requirements and describe how you would like to use STM.  There, we can discuss what limitations we know we have when using VB today.

    The forum is at:

    Thank you for your interest in our work!

    Dana Groff

    Program Manager for STM.NET

  9. Shreeman says:

    It will be really interesting to see where we are heading with the Axum/STM.NET/PLINQ/DyradLINQ/Rx .I wonder why not MS mixed everything into one Framework rather than creating many Subsets .Although its Welcome to see many initiatives are we heading into another LinqtoSql vs. Entity Frx?

Skip to main content