Visual Basic 9 Interview on DDJ

For those interested in the new VB9 language, there is an interview on DDJ with me and my partners in crime Paul Vick, Amanda Silver, together with our more pointy haired, but good, friends Alan Griver, Rob Copeland, Jay Roxe.

The reason I got sold on software transactions, as opposed to joins, is this paper.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


The composable memory transactions paper is discussed here.

Related work => Related problems?

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.


Lack of Scheduling Information

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. ;-)