Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
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.
why is this interesting? if your goal is a language-like syntax, the user should not even have to be aware that the macro is implemented using a try/catch block. so why should he be able to add a catch-block? what's the advantage? is this the only reason that you restart transaction objects instead of destructing and reconstructing them, or is there another? from my viewpoint, it doesn't make sense to "restart" a transaction. when a transaction fails, you can repeat the operations in it in a new transaction. but there is no such thing as "restarting" it. this would require considerable support from resource managers, so that each of them can reuse the transaction object for a new transaction.
_.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.
yes, but what's wrong with throwing an exception that is uncaught in the transaction scope? undoing the transaction is the default behaviour when a transaction object is destructed.
The question is what is the simple case. for an INNER transaction Boost.STM provides a macro
snip
#define BOOST_STM_USE_ATOMIC(TX) \ for (boost::stm::transaction TX; \ ! TX.committed() \ && TX.restart(); \ TX.commit())
I was talking about "simple" from the user's perspective, not implementation-wise. I'd also prefer a macro xxx{} instead of a combination of two macros xxx{}yyy(); but since this is not possible in all cases, it is better to provide only the latter imho. providing another macro only to avoid writing yyy() in some cases(nested transactions) is confusing. you have to understand implementation details in order to decide if you can save yourself writing yyy().
As I said in a preceding post, we can provide initialy both sets of macros and see which set the users use more often.
yes, we can always do that. I'd still like to understand the benefit of the additional macros. you have clearly spent more time than me on this topic and I'm looking forward to the paper, but right now I honestly don't see the benefit. the benefit of the simple macro is 1) a less verbose interface, not having to write a loop each time, and 2) saving the user from the implementation details. when the user needs to have control over code-on-retry etc., using the macros is not less verbose and the user has to be aware of the details that this is implemented as a loop and a try/catch block. having more than one choice on which macro to use even adds complexity.