DISQUS

DISQUS Hello! Phil Dawes' Stuff is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Phil Dawes' Stuff

Jump to original thread »
Author

Transactional Memory is the wrong path to concurrency

Started by phildawes · 9 months ago

I’m on a sleepy late train home from London to Birmingham (trying to avoid the snow and inevitable rail problems tomorrow). This woke me up:
Patrick Logan says STM “…would be the most tragic turn imaginable for programming in the 21st century.”%3 ... Continue reading »

2 comments

  • http://www.dominicsayers.com

    2 years ago

    I think he's right that it could get abused, but he's wrong to say it is therefore a Bad Thing. Database programmers and designers try to avoid contention but the locking and transactional mechanisms are there because it is unavoidable. Not being a multi-core programmer I don't know how well this analogy stretches but it seems to me that code should be shared-nothing as far as possible but that transactional memory is a Good Thing to have for those occasions when shared state is inevitable.

    Probably a good thing that I don't write code anymore :-)
    reply
  • Neil

    2 years ago

    What nonsense. The most tragic turn would be if neither STM nor message-passing concurrency caught on, and we continued trying to build everything with locks.

    I don't see much from Logan in terms of real arguments, except the repeated assertion that we shouldn't share state. Of course minimising shared state is laudable, but you can never squeeze all of the air out of the balloon. If we accept that sharing state, is necessary albeit rare, then STM is exactly what we need to make it tractable.

    The interesting thing for me about this STM-vs-message-passing debate is that we can essentially build Erlang in Haskell (i.e. implement message passing on top of STM) but we can't build Haskell in Erlang (i.e. STM on top of message passing).
    reply

Add New Comment

Returning? Login