Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-12 08:17:42

Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:
>
> One try-catch block instead on two :)
>

has no advantage.

> On TBoost.STM the restat operation is less expensive than creating a
> transaction.

do you wish to change/extend the ResourceManager concept because of this?
in what way?

>
> Sometimes the user can not throw an exception because s/he is handling
> already an exception, on it is in a no throw function destructor, ... In
> these cases it will be more convenient to just state that the transaction
> could only abort.

ok. what does the call to transaction::commit() then do? throw? which  
exception?

>
> This use is simple for the user perspective and efficient from the
> implementation point of view. I respect you wish to provide only a macro,
> but IMO there are more use cases than one on which macros could be used.

ok, my main point is that TRANSACT_ATOMIC/TRANSACT_COMMIT should be  
not made more complicated in favor of more sophisticated use cases.
if there is a seperate set of macros, that's fine.

but if these should not be STM-specific but usable with Boost.Transact  
in general, please describe what changes to the  
TransactionManager/ResourceManager concepts and the basic_transaction  
class you require for implementing the macros. (one of which would be  
reusing transaction objects, as discussed above. what else?)

> With my macros or with yours, the user needs to be aware that the
> transaction block is included on a internal  loop.

not necessarily. when you "return" from a transaction scope, commit()  
isn't reached, so the transaction is not committed.

in this case:

do{
   return 1;
}while(a++ == 5);

you don't expect that the side effects of the while-clause still takes  
effect. so I don't see a problem in the behaviour that "return" omits  
the commit either.
you could of course offer a macro like COMMIT_AND_RETURN.