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

√iktor Ҡlang viktor.klang at gmail.com
Tue Nov 22 11:50:06 EST 2011


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,
√


> Andrew.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
Experts

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111122/13b385cf/attachment.html>


More information about the Concurrency-interest mailing list