Possible deadlock and solution
gyepi at praxis-sw.com
Sun Sep 29 16:46:59 EDT 2002
On Sun, Sep 29, 2002 at 05:32:54PM +0200, Matthias Andree wrote:
> On Fri, 27 Sep 2002, Mark M. Hoffman wrote:
> > I'm with Gyepi here. Locking in order eliminates deadlock. When there
> > are 500 different resources to worry about (like the linux kernel) it's
> > impossible to know or enforce the ordering. Then the "real solution"
> > comes into play. Here, we're talking about two locks - perfect for the
> > "academic" solution.
> Well, the roll-back-and-retry approach is nothing complex and will work
> regardless of future source code changes. If it'd be something overly
> complex, then I'd agree, but adding parameters for the locking order is
> a maintenance nightmare. Don't do it.
I know it is not overly complex, but the current solution is simpler yet.
Note that the new parameter simply determines which databases are locked,
and not the order, which is built into the function.
I am not averse to the roll-back-and-retry solution: but I think it is overkill
for two databases. When/if we merge the multiple database patch in, we'll probably want
to use the more generic locking policy, and in that case, I would want to implement it
as part of the datastore API in order to maintain the current method's simplicity.
More information about the Bogofilter-dev