

Software Transactional Memory: Yay, Ney or Someday? - tobiassvn
http://return42.blogspot.com/2009/07/software-transactional-memory-yay-ney.html

======
jrockway
dons' comment is pretty much spot on. Will STM work for langauges like Java?
Probably not. Does it work for languages like Haskell? Yes.

But anyway, people are very resistant to change in the computer programming
community. New technologies == having to learn something new, and that's
apparently a bad thing. (Look at how many people still hate automatic garbage
collection, even though it's generally faster than manual memory management.
It's scary and new, so let's run away!)

~~~
samstokes
Microsoft seems to think it will work for mainstream languages, as they're
developing an STM implementation for .NET. It's in "incubation", which means
they're not certain to productise it but they are actively working toward
doing so.

There's a good interview with two guys from the tech team on Channel 9:
[http://channel9.msdn.com/shows/Going+Deep/Software-
Transacti...](http://channel9.msdn.com/shows/Going+Deep/Software-
Transactional-Memory-The-Current-State-of-the-Art/)

Worth watching if you're interested in the topic. They discuss some of the
issues raised in the Enfranchised Mind post, and what they're doing about
them. There are some other interesting tidbits about how STM and concurrency
primitives can interact confusingly, and the way they're hooking things like
SQL Server into the STM machinery so that other things besides pure shared
memory access can get the benefits of atomic transactions.

------
jganetsk
It's either yay or ney, there's no someday. There's no reason why we can't use
it now. The implementations are there. You just have to use a pure language,
like Haskell.

