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.

Namaste!

Comments

• Anonymous
  July 27, 2009
  This is an awesome feature. Hopefully it works as expected. Will check it out soon! .NET rocks!

• Anonymous
  July 28, 2009
  This is exciting, I can't wait to check it out!

• Anonymous
  July 29, 2009
  The comment has been removed

• Anonymous
  July 29, 2009
  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.

• Anonymous
  July 29, 2009
  @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: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361647 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?

• Anonymous
  July 30, 2009
  Great, 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.

• Anonymous
  July 30, 2009
  The comment has been removed

• Anonymous
  July 30, 2009
  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: http://social.msdn.microsoft.com/Forums/en-US/stmdevlab/threads Thank you for your interest in our work! Dana Groff Program Manager for STM.NET

• Anonymous
  August 12, 2009
  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?