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

Gregg Wonderly gregg at cytetech.com
Tue Nov 22 16:50:46 EST 2011


On 11/22/2011 12:32 PM, √iktor Ҡlang wrote:
>
>
> On Tue, Nov 22, 2011 at 5:55 PM, Gregg Wonderly <gregg at cytetech.com
> <mailto:gregg at cytetech.com>> wrote:
>
>     On 11/22/2011 10:41 AM, Andrew Haley 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.
>
>
>     I think it's better to say "one way operations", instead of I/O.  Basically
>     it's pointless to attempt to use transactional behavior on a one way
>     operation, unless it can not fail, in which case, you actually do something like
>
>     try {
>        xxx.commit();
>        doOneWayStuff();
>     } catch( ) {
>
>     }
>
>
> That does not compose, you need to be able to do deferred operations at will.

Can you clarify this comment?

Gregg


More information about the Concurrency-interest mailing list