Linked by Eugenia Loli on Sat 2nd Sep 2006 21:07 UTC
.NET (dotGNU too) 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.
Order by: Score:
now this
by Cloudy on Sat 2nd Sep 2006 22:46 UTC
Cloudy
Member since:
2006-02-15

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.

Reply Score: 2

if...
by bytecoder on Sun 3rd Sep 2006 00:13 UTC
bytecoder
Member since:
2005-11-27

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.

Reply Score: 1

Heh
by Ronald Vos on Sun 3rd Sep 2006 23:56 UTC
Ronald Vos
Member since:
2005-07-06

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.

Reply Score: 0

So?
by werpu on Mon 4th Sep 2006 08:20 UTC
werpu
Member since:
2006-01-18

J2EE has done that for ages, what is new about it?
In J2EE you just write @transactional and you have clustered in memory transactions.

Reply Score: 1

RE: So?
by Ronald Vos on Mon 4th Sep 2006 23:16 UTC in reply to "So?"
Ronald Vos Member since:
2005-07-06

Can you compose transactional threads in J2EE to form larger abstractions?

Reply Score: 1

It's not the only approach
by jmcp on Sun 10th Sep 2006 14:17 UTC
jmcp
Member since:
2006-08-06

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.

Reply Score: 1