[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?
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.
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?
<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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest