[MLton] Transactions for ML

[Eric McCorkle]

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".

-- 
Eric McCorkle
Brown University
CS Graduate Student



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070420/7e454978/attachment.htm