Try a different lock detection mechanism.
grep for set_lk_detect, and change it from DB_LOCK_RANDOM to one of:
DB_LOCK_MAXLOCKS
Reject the lock request for the locker ID with the greatest number of locks.
DB_LOCK_MINLOCKS
Reject the lock request for the locker ID with the fewest number of locks.
DB_LOCK_MINWRITE
Reject the lock request for the locker ID with the fewest number of write locks.
DB_LOCK_OLDEST
Reject the lock request for the oldest locker ID.
DB_LOCK_YOUNGEST
Reject the lock request for the youngest locker ID.
Hopefully one of them should work better.
On Tue, 27 May 2003, D.J. Heap wrote:
> This patch did not make a noticeable difference for me on a single or
> hyperthreaded machine. I'm still seeing runs of 20 or more deadlocks in
> a row very often. :(
>
> DJ
>
>
> Branko Čibej wrote:
> > cmpilato@collab.net wrote:
> >
> >
> >>=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu> writes:
> >>
> >>
> >>
> >>>Yes, I was thinking of this when I looked at the trail.c code the other
> >>>
> >>>day. I don't know if it really has to be randomized, though; a simple
> >>>yield -- sleep(0) -- might be enough, given different timing.
> >>>
> >>>
> >>
> >>Is this what you're looking for?
> >>
> >>* subversion/libsvn_fs/trail.c
> >> (svn_fs__retry_txn): Yield control on deadlock.
> >>
> >>Index: subversion/libsvn_fs/trail.c
> >>===================================================================
> >>--- subversion/libsvn_fs/trail.c (revision 6063)
> >>+++ subversion/libsvn_fs/trail.c (working copy)
> >>@@ -150,6 +150,10 @@
> >>
> >> /* We deadlocked. Abort the transaction, and try again. */
> >> SVN_ERR (abort_trail (trail, fs));
> >>+
> >>+ /* Yield; let's see if some of the traffic congestion clears up
> >>+ before we try again. */
> >>+ apr_sleep (0);
> >> }
> >>}
> >>
> >>
> >
> >
> > Yes, something like that. A yield is probably enough on a single-cpu
> > machine; I wouldn't venture to guess about multiple-cpu boxes. D.J., can
> > you rerun your test with this patch applied? Tell us if it makes a
> > difference, etc.? We might end up having a randomized sleep anyway.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 01:19:26 2003