[Haskell-cafe] Software Transactional Memory and LWN

Ryan Ingram ryani.spam at gmail.com
Thu Jun 11 15:23:05 EDT 2009

On Thu, Jun 11, 2009 at 4:38 AM, Ketil Malde<ketil at 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

More information about the Haskell-Cafe mailing list