Microsoft drops Software Transactional Memory

[Brian]

Not directly related to Clojure but I thought this would be of interest to folks:

http://www.infoq.com/news/2010/05/STM-Dropped

http://www.reddit.com/r/programming/comments/c4367/microsofts_experiments_with_software/

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Angel Java Lopez]

Hi people!

A 2008 paper, I just received today via twitter

Software transactional memory: why is it only a research toy?
http://portal.acm.org/citation.cfm?id=1400228&coll=ACM&dl=ACM&CFID=90273999&CFTOKEN=67127907&ret=1#Fulltext

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

[Brian Hurt]

The problem with STM is that it adds significant overheads to modification costs.  In a "classic" imperative programming language like Java or C#, stores to variables compile down to simple memory writes- very cheap.  An STM memory write, by contrast, is 10x or 100x more expensive (depending upon particulars in how the STM is written).  So in functional programming languages, like Haskell and Clojure, writes are rare, so the additional cost is minimal.

For example, consider the case where you're sharing a map of objects across multiple threads.  The standard way to do that in Clojure is to drop an immutable map into a reference cell.  Updating the map only requires one TM write- to the reference cell (one nice thing about immutable data structures is that you don't have to synchronize on them).  A Java implementation would have a mutable map, meaning you'd have O(log N) TM writes.  If each write takes a few hundred clock cycles, the difference between one write and several dozen writes becomes important.

I wrote about this more fully here:
http://enfranchisedmind.com/blog/posts/the-problem-with-stm-your-languages-still-suck/

I'm talking about Haskell, but most of my comments apply to Clojure as well.

Brian

[Patrick Wright]

For more details about Microsoft's work on STM, and the many, many
problems they had to address, see Joe Duffy's blog on the topic
http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx

[James G. Sack (jim)]

On 05/15/2010 02:53 AM, Patrick Wright wrote:
> For more details about Microsoft's work on STM, and the many, many
> problems they had to address, see Joe Duffy's blog on the topic
> http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
>

I have just about zero expertise in concurrency technology or language
design, but even for someone as naive as I am, it seems "obvious" that
many of the headaches and problems discussed above would be at least
grossly simplified by having immutable persistent data.

Given that feature of clojure's design, it seems that concurrency issues
exist in an entirely different (and more tractable) environment.

~jim