Re: [Sks-devel] DB_INIT_LOCK problems?

[Jason Harris]

On Fri, Jul 30, 2004 at 10:10:40PM -0400, Yaron Minsky wrote:
> On Fri, 30 Jul 2004 19:15:45 -0400, Jason Harris <address@hidden> wrote:

> > /usr/local/share/doc/db42/ref/transapp/deadlock.html says:
> > 
> >    Even when Berkeley DB automatically handles database locking, it
> >    is normally possible for deadlock to occur. Because the underlying
> >    database access methods may update multiple pages during a single
> >    Berkeley DB API call, deadlock is possible even when threads of
> >    control are making only single update calls into the database. The
> >    exception to this rule is when all the threads of control accessing
> >    the database are read-only...
> > 
> > /usr/local/share/doc/db42/ref/lock/dead.html says:
> > 
> >   Practically any application that uses locking may deadlock.
> >   ...
> >   While there are data access patterns that are deadlock free (for example,
> >   an application doing nothing but overwriting fixed-length records in an
> >   already existing database), they are extremely rare.
> 
> I think that what they're saying is that any application that uses
> locking can deadlock,  in the presence of multiple threads/processes
> accessing the database.  So, making SKS safe for multi-threaded access

No, one single-threaded process writing a single record which updates
multiple pages will deadlock its own self, due to the internal design
of BDB's locking subsystem, even if it is the only process using a
database.

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
address@hidden _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

pgptvG7fkjEHE.pgp
Description: PGP signature