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

√iktor Ҡlang viktor.klang at gmail.com
Tue Nov 22 16:58:14 EST 2011


2011/11/22 Gregg Wonderly <gregg at cytetech.com>

> 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?
>

methodA() {
  changeSomething
  changeSomethingElse
  sendEmailsToYourCustomers
}

methodB() {
  changeSomething
  changeSomethingAwesome
  drinkAShotOfJaeger
}

methodC() {
  How do I call methodA and methodB here...
  transaction.commit()
  ... and have their dangerous side effects only performed at-most-once here
}



>
> Gregg
>



-- 
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/f90bc515/attachment-0001.html>


More information about the Concurrency-interest mailing list