Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-12 02:22:44

----- Original Message ----- 
From: <strasser_at_[hidden]>
To: "vicente.botet" <vicente.botet_at_[hidden]>
Sent: Friday, February 12, 2010 2:00 AM
Subject: Re: Re:[boost] [transact] code in sandbox

> Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> IMO the transaction must be accesible during the handling of the exceptions.
> 
> why? I see one reason in your examples (although I don't understand  
> force_to_abort, maybe that's another one, see below), and that is  
> committing on exception:
> 
>>>> #define BOOST_TRANSACT_BASIC_RETHROW(TXMGR, TX, E) \\
>>>> catch (E&) {(TX).commit(); throw;}
> 
> why can't the user create his own try/catch block for that?:
> (using your syntax)
> BOOST_TRANSACT_ATOMIC(_) {
>     try{
>       ...
>     }catch(my_exc &){
>       _.commit();
>     }
> }BOOST_TRANSACT_COMMIT();

Yes this is always possible. However, transactions and exception handling are used for the same goal, recover from errors. Thus it is interesting to handle them in the same way and in a single try-cactch block.
 
>>     _.force_to_abort();
> 
> what does this do? retry the transaction but make sure it fails? why?
> why don't you just go ahead and throw an exception that is not caught  
> inside the transaction scope?

When the user wants to undo whatever the transacton block did, the simple way is to abort the transaction. Don't forget that transactions can be used in a single-threaded application to make exception-safe code.

>>> at some point I think the macros loose their benefit and you might
>>> just as well write the loop yourself. e.g. if you need to execute
>>> custom code on retry.
>>
>> You are right. The specific macros are not important. What is  
>> important is that the provided macros can be extended naturaly.
> 
> that's what I'm not so sure of. if you need to control the number of  
> retries or execute custom code on retry, why don't you just write this  
> instead of using macros:
> 
> for(int c=0;c<10;++c){
>   try{
>     transaction tx;
>     ...
>     tx.commit(); 
>     break; 
>   }catch(isolation_exceotion &e){
>     e.unwind();
>     std::cerr << "my custom retry code\n";
>   }
> }
> 
> doesn't seem a whole lot more verbose to me.
> but I'm not against adding more macros for convenience. the one thing  
> I would like is not complicating the simplest use case. the user  
> shouldn't have to to add something like "(_)" if he doesn't need it  
> and has no idea what it is there for. the default use case should be  
> as simple as possible.

I would like also to don't need to add a transaction variable name. I need the name of the transaction variables to implement break and continue in a language-like. From my side, the inclusion of the macros is to be close to what the user will write if the language provided some specific transaction constructs. The user is always free to use directly the class interface.

The question is what is the simple case. for an INNER transaction Boost.STM provides a macro 

#define BOOST_STM_USE_ATOMIC(TX)                                \
    for (boost::stm::transaction TX;                            \
            !   TX.committed()                                  \
            &&  TX.restart();                                   \
        TX.commit())

that the user ca use like

BOOST_STM_USE_ATOMIC(_) {
    // transaction statement
}

In this case every exception scape the transaction block, and will be managed by the outer transaction block. This is simple, recall a possible language statement

transaction {
    // transaction statements
}

The parameter is needed only if we want to return from the transaction block. If needed we can add a simple

#define BOOST_STM_INNER_TRANSACTION                               \
    for (boost::stm::transaction __TX;                            \
            !   __TX.committed()                                  \
            &&  __TX.restart();                                   \
        __TX.commit())

use as follows

BOOST_STM_INNER_TRANSACTION
{
    // transaction statement
}

As I said in a preceding post, we can provide initialy both sets of macros and see which set the users use more often.
 
Best,
Vicente