Boost logo

Boost :

Subject: Re: [boost] [transact] code in sandbox
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2010-02-17 12:30:09


On Wed, Feb 17, 2010 at 3:36 AM, <strasser_at_[hidden]> wrote:
> Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
>>
>> 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.
>
> how do you handle deadlocks?

> even pessimistic RDBMS require a retry-logic on the user's part in case of a
> deadlock, how do you avoid that?

Because I'm using entry-level locking, it is possible to write the
algorithms so that all changes occurring in parallel threads happen
in an agreed-upon order resulting in deadlock-free execution. For
example, sorting all the keys of modified or deleted entries prior
to performing those operations.

I concede that in practice, most users won't do that, unless their algorithms
are so contentious that the effort is warranted. So
yes, I need deadlock handling, and for that, the standard retry loop / exception
handling is appropriate.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk