Lambda the Ultimate

The composable memory transactions paper is discussed here.

There are some interesting similarities to the Gemstone (Smalltalk and Java) persistent transactional memories. the differences are pretty clear: Gemstone Smalltalk is not type checked before runtime; Gemstone Java does not have as good a type system; both Gemstone implementations are multi-user in a single, distributed memory model; both Gemstone implementations are persistent, i.e. a transaction is ACID.

I did not get the sense that this Haskell implementation is persistent / ACID in the database sense. It's also single process and single processor.

The idea of transaction failure allowed to leak read data into the handler is common to Gemstone. Gemstone allows the failed transaction to be fixed and retried if you can get to the hook in the transaction manager. Only system code could do that I recall.

I wonder about this being a desirable approach to concurrency though. Another problem Gemstone has in practice is that with a transactional memory, every external database then implies a two-phase commit or an inconsistency between the transactional memory and the transactional database. In some sense you are no worse off than if your memory is not transactional but customers I know of tended to want their transactions coordinated.

Another less desirable aspect of this is that either distributed virtual memory becomes your bigger model, or you have a different model for distributed systems than for non-distributed. Then you get into distributed garbage collection, which Gemstone also does very well. Whether that is desirable or not... after years of that model I ended up appreciating Erlang's model more.

-Patrick

Random thought on the transactional Haskell paper.

It's a very good paper; I can see that a simple transactional system can be preferred over other solutions for many applications. However, I cannot get a clear view on how stuff is scheduled in the paper; they mention starvation as one possible problem - that is a huge show stopper for a number of applications (say like a web-application). I guess such a problem could be solved by assuming a fair scheduler - but then, hey, this often means one can say goodbye to responsiveness of the overall system.

Hmm, I predict a new paper: transaction based concurrent Haskell with an EDF/priority (ceiling) scheduler. ;-)