Re: [Sks-devel] DB_INIT_LOCK problems?

[Jason Harris]

On Sun, Jul 25, 2004 at 09:44:40PM -0400, Yaron Minsky wrote:

> My problem is that I don't understand why there are ever deadlocks at
> all.  Both "sks db" and "sks recon" are single-threaded applications. 
> They communicate with each other in various ways, but they don't
> access each other's databases at all.  So the fact that there are ever
> deadlocks of any sort suggests to me that my code is doing something
> that's just wrong.  I'd prefer to figure out what that is before
> making the code as it is more robust to being interrupted by the
> deadlock avoider.
> 
> That said, I've looked at this a few times, and haven't been able to
> figure out what I'm actually doing wrong.  So if you have any thoughts
> I'm all ears.

[2nd reply]

/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.

-- 
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

pgpOvQnf6ikcX.pgp
Description: PGP signature