[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?
benjamin.john.evans at gmail.com
Tue Nov 22 02:12:45 EST 2011
I utterly disagree.
JSRs should be places for standardization of existing mature or
They are not a place for speculative experimentation. That should be
done in a regular OSS project, or e.g. as part of mlvm-dev (as it
seems to be that transactional memory is a VM feature, not a purely
I also can't believe that we've got this far in the discussion without
anyone mentioning Clojure's approach to STM, including co-ordination
of its ref constructs. In particular, the retry semantics, and the
requirement that transactions be side-effect-free seem incredibly
pertinent to this discussion.
Completely agree about the need for "managed concurrent references"
though, and also that support for legacy libraries seems pretty much
However, let's not kid ourselves. Java is the world's
centre-of-the-mean programming language - and unenforceable
compromises such as Clojure's: "Transactions must be side-effect-free.
Or else." are not practical for Java. If they're the best we can do,
then we should leave STM out as a feature.
On Mon, Nov 21, 2011 at 11:39 PM, Guy Korland <gkorland at gmail.com> wrote:
> Again, I think such discussion should be done under a context of a JSR.
> But, for your comment, using "managed references" or some other explicit
> model to mark managed references in my opinion might be a blocker for adding
> STM to Java.
> I don't see any chance for successful Java STM which is not composable and
> supports calling legacy libraries.
> Unless I'm missing something?
> Date: Mon, 21 Nov 2011 23:57:21 +0100
> From: ?iktor ?lang <viktor.klang at gmail.com>
> To: R?mi Forax <forax at univ-mlv.fr>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
> what about Java?
> <CANPzfU8-fH=Sgc6a1d8xvAtsDrMbWXVoaJ3udV5YH2KoqUwwfQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> I think that managed references is the only way to go when it comes to STM.
> You can't make it implicit since traditional "OO"-code is completely ridden
> with side effects.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest