[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?
gkorland at gmail.com
Mon Nov 21 18:26:17 EST 2011
First, I think this is a discussion that should be done as part of a JSR.
Meaning, I think the wheels should start moving and then we'll carve out
the best solution.
As for your questions:
1. There're two realistic options to handle I/O and one naiive.
In other words (a) you can ignore I/O or Native code call as you do
with I/O or Native call when called under a lock context (You don't enforce
any memory semantic). (b) you can abort any transaction trying to get
outside the scope of the JVM. (c) you can hope for transactional I/O but it
won't help for Native method call.
I think a realistic solution should go with (b).
2. The semantic we choose in DeuceSTM was to commit a transaction that
throws an application Exception, and that since (sadly) throwing an
Exception is a valid way to return from method in java and pretty common.
Also again when running under a context of coarse grained lock Exception is
a valid way to get out of it.
> Date: Mon, 21 Nov 2011 23:03:31 +0100
> From: R?mi Forax <forax at univ-mlv.fr>
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
> what about Java?
> Message-ID: <4ECACAB3.3000001 at univ-mlv.fr>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> 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++.
> > Guy
> And how do you solve the IO problems (when you retry) ?
> Also the semantics chosen by Microsoft when an exception is thrown
> and the one chosen by GCC is not the same.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest