On 4/20/07, <b class="gmail_sendername">Daniel C. Wang</b> &lt;<a href="mailto:danwang@cs.princeton.edu">danwang@cs.princeton.edu</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Not to start a flame war about STM, but if you dig deep into the<br>semantics it&#39;s not clear that it actually makes writing concurrent<br>programs any easier. </blockquote><div><br>I was about to state exactly the same thing. Though I want to add a couple
<br>from a slightly different angle: Haskell implements STM by noting that we can regard [&#39;a STM]<br>as a monadic computation of type &#39;a. Such a computation can be executed atomically:<br><br>val atomic: &#39;a STM -&gt; &#39;a IO
<br><br>where IO is the Haskell IO monad capturing I/O operations. There is a special retry-operation:<br><br>val retry: &#39;a STM<br><br>to use when things goes wrong and the transaction has to be retried. The most interesting semantic
<br>operation is that of<br><br>val orElse: &#39;a STM -&gt; &#39;a STM -&gt; &#39;a STM<br><br>with informal semantics [orElse a b] means try to run [a] if that transaction fails, then try to run [b]. If that fails then [orElse a b] fails. Take a look at the paper [1] for the whole story, including operational semantics, implementation details etc. If I remember correctly, purity of Haskell becomes an important factor in the implementation.
<br><br>Having said that, my *intuition* leans towards a message-passing style concurrency more than a shared-memory style concurrency. One interesting aspect of message passing is that it does not need to be very complex to cover most problems one may face. Erlang has an extremely simple message-passing primitive and you get good speedups on multicore machines with a few changes to programs. If Intel, AMD and Sun will scale on multiple cores in the future I will argue that message-passing style will tend to win in the long run, be it Erlang style concurrency, CML rendezvous, Alice ML futures etc. I think this is so because I find it much easier to write concurrent programs in a message-passing style than in a shared-memory style.
<br><br>[1] <font size="-1"><span class="a"><a href="http://research.microsoft.com/~simonpj/papers/">research.microsoft.com/~simonpj/papers/</a><b>stm</b>/<b>stm</b>.pdf</span></font></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It probably makes writing *shared memory* based<br>concurrent programs easier. However, if you&#39;re programming in SML and<br>not something like C there are so many other ways to do concurrency<br>better that STM is not an obvious win.
</blockquote><div><br>Exactly. Elaborated above. <br></div><br><br></div>