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

Guy Korland gkorland at gmail.com
Tue Nov 22 12:30:43 EST 2011


What do you mean by you can't detect I/O? You can detect I/O also when
calling external libraries.

Guy

Date: Tue, 22 Nov 2011 17:50:06 +0100
From: ?iktor ?lang <viktor.klang at gmail.com>
To: Andrew Haley <aph at redhat.com>
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
       what about Java?
Message-ID:
       <CANPzfU9VXNsjARFS9byt2DVSVLER3pWr2e3UsPktjA_1tapjuw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.
Also, you cannot reliably detect blocking or non-termination, which makes
this global lock the Devil(tm)

Cheers,
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111122/ffedc599/attachment.html>


More information about the Concurrency-interest mailing list