Simon and Tim (and team) are working on a programming technology called Software Transactional Memory (STM) which provides an elegant, easy to use language-level abstraction for writing concurrent applications that is based on widely-understood conceptual constructs like Atomic operations (and, well, Transactions…). Simon, Tim and team do all the nasty locking work for you. With STM-enabled languages, you can just concentrate on the algorithms at hand and leave the low-level heavy lifting to the sub-system.
The Age of Concurrency: Software Transactional Memory
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
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.
J2EE has done that for ages, what is new about it?
In J2EE you just write @transactional and you have clustered in memory transactions.
Can you compose transactional threads in J2EE to form larger abstractions?
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.