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

Andrew Haley aph at redhat.com
Wed Nov 23 10:54:35 EST 2011

On 11/23/2011 01:08 PM, √iktor Ҡlang wrote:
> 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?

No.  It simply means that if you're calling random code from within a
transaction you have to expect the worst, which in this case is a
relaxed 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.

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

> 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.

Indeed, but with STM, as with so many other things, there's more than
one way to do it.  I don't really like relaxed transactions, but
they've been adopted into C++ for pretty good pragmatic reasons.


More information about the Concurrency-interest mailing list