Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-17 03:27:45

----- Original Message ----- 
From: "Bob Walters" <bob.s.walters_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 17, 2010 7:25 AM
Subject: Re: [boost] [transact] code in sandbox

On Fri, Feb 12, 2010 at 7:54 AM, Vicente Botet Escriba
<vicente.botet_at_[hidden]> wrote:

> With my macros or with yours, the user needs to be aware that the
> transaction block is included on a internal loop. Otherwise his code could
> not work. For example with your macro (that hides the transaction variable)
> the user is unable to exit successfully from the transaction block.
>
> int f() {
> BOOST_TRANSACT_ATOMIC {
> ...
> return 1; // do not commits
> ...
> }BOOST_TRANSACT_COMMIT;
> }
>
> will not behaves as the user expects. With the STM macros the user could do
>
> int f() {
> BOOST_TRANSACT_ATOMIC(_) {
> ...
> _.commit(); return 1;
> // or
> BOOST_TRANSACT_RETURN(_, 1);
>
> ...
> } BOOST_TRANSACT_RETRY(_);
> }

Actually, looking back at the start of this whole thread, the original
macros were
'do atomic{' and '}commit()' to specifically help show the do/while loop.  And
looking at the above, the RETRY macro at the end of f() doesn't do as effective
a job conveying the presence of the loop.  (IMHO.)

You've made a good point here.  The macros can hide too
much from the end user.  That is one of the things underlying my own
dislike of macros.
They save time writing code, but make it harder to read, and debug.

The use of macros for these loops should be optional.  For that
matter, the loops
are optional.  In my library, a user can employ pessimistic locking
conventions to
ensure no chance of an isolation_exception, and in the process, would
not need the
retry loop.

>> 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.
>
> Maybe you are right, may be not. All these depend on whether we found a good
> macro name for each common use case. I hope we will find out these common
> use cases and appropriated names together.

I agree with Steffan on this point.

Perhaps one way of approaching this, with a library like
Boost.Transact is to have
a clear, explicit model for dealing with a transaction, and provide some macros
for the most common use case we can think of, and which we agree to be generic
enough to apply to all 3 libraries.  Additional macros, specific to
capabilities that are
only in one or two of the libraries could be provided with that
library.  For example,
I do not currently have any capability to assign transaction priorities.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi, 

the macros try to hide the complex code the user will need to hand write to get the same result. That means that if a loop is needed, the user will use a loop, and the problem will be on the side of the user. I think the library authors need to consider the situations the user will be in face of, to see if the provided interface is enough. The language-like macros, are just a mean to explore the domain.

I don't think neither the criteria to don't accept capabilities that are only in one or two of the libraries. We need to explore what is useful to have and what is not useful independently from which library needs this now.

The mix of optimistic and pessimistic strategies needs a careful design. On Boost.STM we have a LocakAware TM mechanism that could inspire us in this point. Whether the Transact library will take care of this requirement will depend on whether we found a good solution.

We need to consider how contention management helps to avoid starvation with optimistic synchronization. Transaction priorities could be a way, other need to be considered, and see if the interface is enough open to let the user choose its contention management strategy.

We are at the beginning, compiling requirements, evaluating different interfaces, etc, .. This would take some time and I'm sure that at the end we will reach an interface that satisfy the user and the author of the 3 libraries.
I would prefer to left process management considerations out of this discussion and that we concentrate the discussion on concrete cases.

Best regards,
Vicente