[MLton] Transactions for ML
ericmcc at cs.brown.edu
Fri Apr 20 08:59:09 PDT 2007
I accidentally replied only to Daniel, not to the list as well
On Apr 20, 2007, at 1:53 AM, Daniel C. Wang 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. 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.
I think SML represents a very interesting balance of functional
programming with the ability to use imperative structures. However,
unlike languages like Java and C++, where you are forced to program
in an inherently sequential manner, SML encourages FP as the norm,
and imperative structures seem to only be convenient where they are
actually beneficial. If you translate this into concurrent
programming, Java and C++ require shared memory, because it's the
only thing that makes sense for them. But if you get far beyond
"embarrassingly parallel" applications, the problem becomes one of
complex data structures and execution paths, not just
synchronization. This is where message-passing comes into play.
On the other hand, transactions have advantages over message-passing:
transactions have an infinite consensus number, whereas most
synchronous channel implementations have only consensus number 2, and
asynchronous channels cannot solve consensus at all, transactions (in
theory) can perform as well as lock-free structures, and no worse
than coarse-grained locks. The key lies in designing a program so
that shared data is relatively uncontested.
My point in all this is that I have a suspicion that the same factors
that encourage side-effects only where they are a good idea will give
rise to very well-crafted, scalable concurrent programs using a
combination of STM and messaging. The style of a small base of
shared state which threads access with low contention in between
performing isolated computation is what designers in languages like C+
+ and Java strive to achieve, and I have a suspicion that in SML,
that will come very naturally.
Of course, this is all mere speculation until a few people try
building some complex applications this way and say "yes, it works
great", or "no, you run into problem x".
CS Graduate Student
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MLton