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

√iktor Ҡlang viktor.klang at gmail.com
Wed Nov 23 08:08:38 EST 2011

2011/11/23 Andrew Haley <aph at redhat.com>

> On 11/22/2011 04:50 PM, √iktor Ҡlang wrote:
> > On Tue, Nov 22, 2011 at 5:41 PM, Andrew Haley <aph at redhat.com> wrote:
> >
> >> On 11/21/2011 10:03 PM, Rémi Forax wrote:
> >>> On 11/21/2011 08:04 PM, Guy Korland wrote:
> >>>> Not all the issues are solved, but it seems like most of the issues
> >>>> have good answers.
> >>>> Also, notice that in .NET they have issues which Java doesn't have
> >>>> like Native code and pointers in C++.
> >>>
> >>> And how do you solve the IO problems (when you retry) ?
> >>
> >> There are basically two practical approaches to I/O:
> >>
> >> 1.  Don't do I/O in a transaction.
> >>
> >> 2.  Convert the transaction into a "relaxed" transaction, i.e. one
> >> that uses a single global lock.
> >
> > Problem is that you can't reliably detect IO, so that makes any call to a
> > 3rd party jar a can of worms.
> No more than usual: if you don't know what a library might do, you're
> taking a risk.

You might have known it at the time of writing the code, but since then the
3rd party jar has been updated, now you're in trouble.

>  If you're not certain what a transaction might do, you
> have to treat it as a relaxed transaction.
> > Also, you cannot reliably detect blocking or non-termination, which makes
> > this global lock the Devil(tm)
> Well, yes.  Again, if you don't know what a library might do, you
> shouldn't be calling it.

You mean that you have full knowledge of the inner workings of all your 3rd
party (and stdlib for instance) dependencies?

Did you know that java.net.URL does a DNS resolve in .equals?

>  This is true regardless of whether you're
> in a transaction.

I'm just saying that making the transactions completely transparent without
managed references gives the impression that there is no worries to be had,
which is quite to the contrary.

I'm not trying to bash STM here, I think it's great for some concurrency
control problems like consensus.
In Akka we went the Clojure route with managed references and it's worked
out great.


> Andrew.

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111123/cb5e59be/attachment.html>

More information about the Concurrency-interest mailing list