On Thu, Jun 11, 2009 at 4:38 AM, Ketil Malde<ke...@malde.org> wrote: > Ignoring the paper in the interest of laz...expedience, I guess the > crucial part is committing the transactions - you'd either need locks > or to single-thread the committing.
It's possible to single-thread the commit without locking using lock-free mechanisms, but it's extremely tricky. The current proof-of-concept implementation uses locks under the hood, but only during commit. One big benefit of STM, in fact, is that you can avoid using locks until commit-time; it's very difficult to write correct concurrent code even with locks around the entirety of your transaction (as is used in, for example, Java's "synchronize" methods). Being correct while delaying all locking until updates need to be made is impressive in itself. The other benefit is that you free the programmer from having to worry about locks; they are an implementation detail. There's no technical hurdle towards switching all of Haskell's STM code to a lock-free implementation; client code using STM doesn't have to change at all. Saying "all current implementations use locks" is kind of a cop-out; it would be like saying ten years ago "all current cars use gasoline, so why bother researching better batteries?" I am confident that there will be a lock-free implementation of STM in Haskell's future. -- ryan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
