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

Andrew Haley aph at redhat.com
Wed Nov 23 06:54:34 EST 2011

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.  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.  This is true regardless of whether you're
in a transaction.


More information about the Concurrency-interest mailing list