Re: [tlug] STM (was: Re: work times & accommodation @tokyo)

["Stephen J. Turnbull" <stephen@example.com>]

Attila Kinali writes:

 > For any given solution, you only have to pick the right
 > problem to make it look good.

And with enough solutions, you can solve lots of problems.  STM,
especially as implemented in Haskell, is a very elegant solution to a
useful class of concurrency problems.

 > I've read it, though not completely understood. But IMHO
 > STM is not the silver bullet to solve all concurency problems.

Well, that's what I said.  Nor has Curt made any claims to the
contrary that I can detect.

 > Actually, i think STM has more problems under the hood than
 > does conventional locking have. But it does serve as a different
 > abstraction to see problems in a different light.

You're referring to stuff like Patrick Logan's blog post?
http://patricklogan.blogspot.com/2007/02/misguided-road-not-to-be-travelled.html

While Patrick is obviously both smart and experienced in the field,
he's also responding to the "seeing nails through the eye of a hammer"
attitude of so many recent grads who majored in Java (or Haskell)
rather than software engineering.

I mean, this cracked me up:

    In practice banking systems do this with asynchronous messaging
    and post-hoc reconciliation.

Well, no sheeyit, Sherlock, but what else do you think the optimistic
transaction implementation does?  So you push the problem to a higher
level, it's still there.  Transactions are the right way to solve the
problem, and the questions are at what level do you do it and how much
ACID do you have to drop?  David Hopwood almost explicitly calls him
on it:

    STM (at least as normally proposed) is shared-state, optimistic
    transactions. Its complexity and performance problems come from
    the shared state and the optimistic scheduling, not the
    transactions. It's possible to support transactions in a
    shared-nothing model, and that still provides the same (actually
    better) composability.