Post a Comment
looks like good work.
The underlying paper is far less fluffy than that random thingie from IEEE mentioned here a few days ago, and it has a bibliography that says the authors are familiar with the literature.
I'm not personally a fan of transactional models because of the overhead, but these guys are making progress in an area where there are some interesting problems that can be solved.
If this is for an imperative language, it seems that making the common, non-annotated mode declarative would be a bad thing, as it completely contradicts every other imperative language in existance AFAIK. Other than that, it looks almost identical to the other concurency approaches for imperative languages that require you to separate concurrent code from atomic code in a rather verbose manner.
It seems to be exactly what IEEE was trying to explain, but wasn't able to.
This definitely seems a way forward, but I fear it will go the same path as several extremely exciting programming languages have gone: a core of fans, and a world ignorant of it's existance because it's too far removed from what they know.
Much depends on how easy it is to learn and implement of course.
There are researchers at Sun Microsystems who are working on a hybrid transactional memory solution http://scholar.google.com/scholar?hl=en&lr=&q=hybrid+transactional+...
which is supposed to resolve the problems that both software-only and hardware-only transactional memory systems have.






