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

Gregg Wonderly gregg at cytetech.com
Tue Nov 22 11:55:22 EST 2011


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( ) {

}

so that you do it to create the atomic view, but you have to be able to 
guarantee ACID and completion.

Gregg


More information about the Concurrency-interest mailing list