[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?
viktor.klang at gmail.com
Tue Nov 22 13:33:30 EST 2011
On Tue, Nov 22, 2011 at 6:30 PM, Guy Korland <gkorland at gmail.com> wrote:
> What do you mean by you can't detect I/O? You can detect I/O also when
> calling external libraries.
Perhaps I'm missing what level you were planning to add this.
> 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)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest