Re: [Sks-devel] DB_INIT_LOCK problems?

[Yaron Minsky]

On Fri, 30 Jul 2004 19:15:45 -0400, Jason Harris <address@hidden> wrote:
> 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.

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
clearly requires making it handle interrupts by the deadlock monitor
gracefully.

But what makes me think that I've done something terribly wrong is
that SKS locks up when locking is enabled, even when it's the only
process running.  That I don't understand.  In a previous message, you
mentioned that you thought that it actually got blocked on select, not
on a database operation.  Did I understand that correctly?  And if so,
do you know where in the code that lockup occurs?

y