[MLton] Transactions for ML

[Jesper Louis Andersen]

On 4/20/07, Daniel C. Wang <danwang at cs.princeton.edu> wrote:
>
> Not to start a flame war about STM, but if you dig deep into the
> semantics it's not clear that it actually makes writing concurrent
> programs any easier.


I was about to state exactly the same thing. Though I want to add a couple
from a slightly different angle: Haskell implements STM by noting that we
can regard ['a STM]
as a monadic computation of type 'a. Such a computation can be executed
atomically:

val atomic: 'a STM -> 'a IO

where IO is the Haskell IO monad capturing I/O operations. There is a
special retry-operation:

val retry: 'a STM

to use when things goes wrong and the transaction has to be retried. The
most interesting semantic
operation is that of

val orElse: 'a STM -> 'a STM -> 'a STM

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.

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.

[1] research.microsoft.com/~simonpj/papers/*stm*/*stm*.pdf

It probably makes writing *shared memory* based
> concurrent programs easier. However, if you're programming in SML and
> not something like C there are so many other ways to do concurrency
> better that STM is not an obvious win.


Exactly. Elaborated above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070420/c0036abc/attachment.html