STM.NET: Who. What. Why.

Play STM.NET: Who. What. Why.

The Discussion

  • User profile image

    Fantastic. I'll definately be giving this a workout. You folks have been cooking up some awesome technology. Can't wait in particular to get my paws on Erik and Wes's "Rx" framework in the next VS2010 beta.

  • User profile image

    I'm guessing you have to watch the first STM video to understand what they are talking about here?

  • User profile image

    cool stuff Smiley an extremly complicated thing wrapped up in an extremly simple syntax (soon):


    someNumber ++


    this is why i love .net,  its embraces academic stuff but also remains practical Smiley


    but am i understanding correctly that the stm stuff is only used when you actually invoke it? if i dont use the stm stuff at all, is there a perf diffrent between the and the regular .net?

  • User profile image

    ok, I will admit it. I don't understand how all of this works. What is the method by which the system determines that a transaction completed without the shared memory being mucked up by another transaction from another thread? Maybe all objects affected are marked with a unique transaction id. At transaction commit time all the affected objects are checked that their "most recent affecting transaction id" = transaction id of the committing transaction.  Or is there a List<object> of all objects affected by all transactions? When committing the transaction, scan this master list from the start of the committing transaction to the end of the list. If the affected objects appear elsewhere in this range of the list, the transaction cant be committed.


    At transaction commit time are any tradtional locks employed? Is so, is the problem with locks more one of the programmer having to decide when and how to use them vs the system wide performance hit of the lock itself?


    I suggest that locks themselves be covered in a C9 episode. Do locks run faster on current microprocessors than in the past? Can each core of a processor set and release locks concurrent with other cores?


    On topics such as this, where slow viewers such as myself have to repeat and think about the material to understand it, can I suggest sub titles be displayed on the screen? Or a printed transcript?  I tried to view the original video in this sequence, the one of the two researchers in England.  The fellow on the right was so soft spoken, with a thick accent and poor white board penmanship. I could not follow what he was saying.



  • User profile image
  • User profile image

    thanks Charles.  Was able to watch the first 30 minutes of that video and what was discussed was the rational for using the STM library functions. Not how the STM framework does what it does.


    If I was to write my .NET transaction code in a lock free, STM kind of way ( w/o using STM.NET ), how would I do it? Perhaps code a first pass that assembles all the objects involved in the transaction and composes the executable steps involved. Then you acquire a lock, run the steps against the assembled objects and release the lock.  This 2nd pass being the equivalent of the commit cycle in STM.NET. Just guessing.


    another suggestion for the C9 videos.  Check out They provide an overview of what is discussed in the video. With links to the point in the video where the sub topic is discussed.  Just something to spend the extravagant C9 production budget on. Smiley






  • User profile image

    This is actually something we are thinking about Wink And there's something even cooler in the works... Stay tuned,





    PS: The STM team blog contains a great del of information -> and the Programming Guide is your friend ->

  • User profile image

    I gave STM.NET a try the first week it was released. 


    The basic API usage is simple: for most problems, a simple "put this code inside Atomic.Do block" does the trick. Very cool.


    The support is great, too. I posted a complex, real-world problem we are facing at the company I work for, and asked how STM.NET could be applied. Several of the guys quickly responded with some excellent suggestions.


    So, what does the future hold for STM.NET? The main concern, I think, is the performance. A 5-7x perf hit over non-transaction code is hefty and daunting. But I suspect the team is already working on these perf issues.


    I'll be keeping a close eye on this project. 

  • User profile image

    thank much!


    Generic Comment Imagecomputerslanditcomputer computerslookup laptop video card

Add Your 2 Cents