[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?

Stefan Marr concurrency-interest at stefan-marr.de
Wed Nov 23 12:19:05 EST 2011

On 23 Nov 2011, at 17:52, Ben Evans wrote:

>> Whoever said that?  For STM to work well transactions should be small,
>> short-lived and not do I/O.  I think everyone here knows that, at
>> least.
> 3) They must have a use case which is so compelling to a large subset
> of Java developers, that the feature cries out to be included - so much so
> that it's capable of overcoming a default position of not adding any
> new features.

Our experience from teaching with Clojure's STM is that the I/O problem leads to a situation where STM is not really of help.

The hard part is still the same as with locking: defining what are the atomic steps and then properly handling the potential data races between the steps.

If you do it like Clojure, excluding I/O from transactions, the hard problems are still all over the place.

You might get some additional parallelism out of the system for 'free', but the conceptual problems the programmer has to solve shift only slightly.

Best regards

Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

More information about the Concurrency-interest mailing list