Boost logo

Boost :

Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
From: strasser_at_[hidden]
Date: 2010-02-21 11:37:41

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> inside the retry-clause the transaction object is destructed and no
>> new one is constructed yet. STM could provide an API for setting the
>> priority of the next transaction, using thread-specific storage to
>> support this.
> I would prefer the transaction be available on retry. Of courset,
> this need to have a restart function.

to me this seems similar to

if(int v=f()){
   //v is not in available here.

since the retry{} clause is syntactically a new scope.

>>> * Should the following compile?
>>> begin_transaction
>>> statement1;
>>> statement1;
>>> end_transaction;
>> it currently does. if we want to adhere to the syntax of a language
>> extension:
>> transaction /statement/
>> we could enforce this by wrapping the user code in

> if(false);else
> works as expected.

ok, will add that.

> There is yet a drawback to your current implemntation:
> * when the commit done on the destructor of the
> commit_on_destruction variable fails, you will throw an exception on
> a destructor. If the destructor is called due to a thrown exception
> the program will terminate. So, ~commit_on_destruction() should not
> throw.

this can not happen. see the call to nullify(). the whole lifetime of
commit_on_destruction is wrapped in a try{} clause. if it throws,
commit_on_destruction is nullified.
so ~commit_on_destruction does not throw if the scope is exited by
exception, and I see no problem with throwing from a destructor
otherwise, not even in the case the macros are used in user's
am I missing something?

> I have resumed in the following pseudo code the code generated by my
> macros depending on whether
> * the current transaction block is in a loop IN_LOOP
> * there are specific exception hadlers HANDLER_SEQ
> * there is a specific retry (RETRY)

I don't quite understand what you're trying to say in this paragraph
and the following pseudo code. defining a grammar for language
extension/code transformation, or anything directly related to the

could you please comment on the following case, as I'm not sure what
the solution is:

     if(something) break; //(1)
     if(stop_trying) break; //(2)

a) keep the current behaviour, (2) does not break the user loop, but
the internal one
b) make (2) break the user loop
c) prohibit using control statements in retry{} clauses

I tend to b).
this would mean that the user has no easy way to stop retrying a
transaction, but has to use c++ flow control for that, like exceptions
or an own loop he can "break". but a) and c) would be pretty
surprising to the user.

e.g., retrying max. 5 times:

     if(retries++ == 5) throw my_exc();
}catch(my_exc &e){
   //tx failed

on a related note, I think it should not be possible to rethrow from a
retry{} clause:

   throw; //error

the fact that an isolation_exception was caught is an implementation
detail, so we should move the user's code on retry out of the catch{}
block. (which is not a problem since the "break" above skips the part
below of it anyway)


Boost list run by bdawes at, gregod at, cpdaniel at, john at