
A (brief) retrospective on transactional memory - blasdel
http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
======
gruseom
This is a fascinating account of the difficulties involved in implementing
STM, written by someone who worked on the problem for several years and ended
up disillusioned about it. The article is unusual, even highly unusual, in how
frank and substantive it is. (By "substantive" I mean grounded in experience.)
People nearly always argue for or against things like STM based on whether or
not they _like_ the idea, which leads to a lot of (not necessarily
intentional) hype/FUD. By contrast, this article contains hard-won
intellectual honesty. The author worked hard on the problem with a smart team
for a long time, so the fact that he was forced to change his mind is
significant. I'm glad I read it through; it gets more readable (and more
dramatic) towards the end.

I don't understand all the details, but the three "disillusionments" that end
up knocking their efforts off the rails seem surprisingly obvious. These are:
(1) what if a transaction contains code that talks to an external system; (2)
what if non-transactional and transactional code write to some location at the
same time; and (3) what if code reads a write that was performed by a failed
transaction but hasn't yet been rolled back. Design problems are always more
obvious in hindsight, of course, but surely these issues were known?

Another question I have: what's different about Clojure's and Haskell's STMs
that allow them to escape the same fate (if they do)?

