Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-11 15:29:29

Zitat von \"vicente.botet\" <vicente.botet_at_[hidden]>:
> the catch has no access to the transaction variable as it out of
> scope (already destructed).
> Some times it is interesting to increase the priority of a
> transaction to avoid starvation. In this case we need to be able to
> access the transaction.

wouldn\'t that then be a new transaction with an increased priority,  
after the first transaction failed? why do you keep the transaction  
object and restart it instead of just creating a new transaction  
object (possibly with an increased priority)?

> BOOST_TRANSACT_ATOMIC(_) {
>
> } BOOST_TRANSACT_BEFORE_RETRY(_) {_.increase_priority(); }.

since setting a priority would be resource manager specific, you\'d  
have to access the resource transaction:

TxMgr::resource_transaction(TxMgr::active()).set_priority(...)

(or a simpler shortcut defined by your library, but my point is that  
it can\'t be a member function of basic_transaction)

>
> On Boost.STM we have developed some macros (see
> stm/branches/vbe/boost/stm/language_like.hpp) . Next follows the
> Transact adaptation of some of them.
>
> #define BOOST_TRANSACT_BASIC_ATOMIC(TXMGR, TX)\\
> for (boost::transact::basic_transaction<TXMGR> TX; \\
> ! TX.committed() && TX.restart_if_not_inflight(); \\
> TX.no_throw_commit()) try
>
> #define BOOST_TRANSACT_BASIC_RETRY(TXMGR, TX) \\
> catch (boost::transact::isolation_exception &i) {}
>
> #define BOOST_TRANSACT_BASIC_BEFORE_RETRY(TXMGR, TX)
> catch (boost::transact::isolation_exception &i)
>
> #define BOOST_TRANSACT_BASIC_RETHROW(TXMGR, TX, E) \\
> catch (E&) {(TX).commit(); throw;}
>
> #define BOOST_TRANSACT_BASIC_ABORT_ON_EXCEPTION(TXMGR, TX, E) \\
> catch (E&) {(TX).force_to_abort();}

could you explain a situation in which you\'d use those other macros?
to me, the macros are a simplified syntax for the most common use  
case, not a syntax which covers every possible use case you could  
think of.
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.

if you think some of those macros would be widely used, please explain  
which ones and what the functions in the macros like  
no_throw_commit/force_to_abort etc. do.
some of this seem resource-manager specific again.

> BTW, what unwind does? Could you explain the problem it intend to solve.

unwinding nested transaction stack.
an isolation exception thrown inside a nested transaction might e.g.  
make it necessary to rethrow it until the outermost transaction is  
destroyed.
for example:

do atomic{
   loc<pers_type> pers_obj=...;
   do atomic{
     //pers_obj is deleted by another transaction at this point
     cerr << pers_obj->value; //throws
   }commit();
}commit();

if the isolation exception would only cause the innermost transaction  
to be repeated, it would be repeated forever, since pers_obj is not  
coming back.

via unwind() the resource manager throwing the exception can control  
up to which transaction on the stack the isolation_exception is  
rethrown. see exception.hpp.

> There are a lot of other macros. I\'ll present all these and more as
> for example how to exit succesfully from a transaction block (return,
> break, continue or goto) at BoostCon.

justin mentioned a to-be-released paper about that some time ago, has  
this been published in the meantime?

>
> Let me know if you want I add them to Boost.Transact;

if we can identify another common use case that is not resource  
manager specific, sure. if it is Boost.STM-specific, your library is  
the right place to define the macro.