http://phildawesstuff.disqus.com/enThu, 08 Feb 2007 12:43:54 -0000http://www.phildawes.net/blog/2007/02/08/transactional-memory-is-the-wrong-path-to-concurrency/#comment-2753533<p>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.</p><p>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.</p><p>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).</p>NeilThu, 08 Feb 2007 12:43:54 -0000http://www.phildawes.net/blog/2007/02/08/transactional-memory-is-the-wrong-path-to-concurrency/#comment-2753532<p>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.</p><p>Probably a good thing that I don't write code anymore :-)</p>http://www.dominicsayers.comThu, 08 Feb 2007 04:46:44 -0000