On 01/26/2011 05:21 AM, Philip Martin wrote:
Philip Martin<philip.mar...@wandisco.com> writes:
Philip Martin<philip.mar...@wandisco.com> writes:
Create two repositories with a pre-commit hook that sleeps for 20
seconds. Start two threaded svnserve processes listening on different
ports.
svnserve -Tdr.
svnserve -Tdr. --listen-port 3691
Commit:
svn mkdir -mm svn://localhost/repoA/X1
svn mkdir -mm svn://localhost:3691/repoB/X1
svn mkdir -mm svn://localhost/repoB/X2
svn mkdir -mm svn://localhost:3691/repoA/X2
All four commits complete. Do I need to cause the thread to spin rather
than wait for a hook script?
That's not right, it just tests commit contention. What I need to do is
make the server spin while holding the txn-current-lock, that will
require some temporary code. I still don't see how it can deadlock.
This patch causes the FS code to spin for about 10 seconds (a debug
build on my machine) while holding the lock. The results are not
exactly what I expected.
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1063629)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -583,6 +583,14 @@
err = body(baton, subpool);
}
+ if (!strcmp(lock_filename, path_txn_current_lock(fs, pool)))
+ {
+ int i, j, k = 0;
+ for (i = 0; i< 200000; ++i)
+ for (j = 0; j< 10000; ++j)
+ k += j + i;
+ }
I'm guessing a sleep would also work well here?
+
svn_pool_destroy(subpool);
#if SVN_FS_FS__USE_LOCK_MUTEX
I start the four commits above, one after the other with a small delay
between them. The commits run in parallel and they all block, then
after about 10 seconds the first two complete, and then the third fails
with:
svn: Can't get exclusive lock on file
'/home/pm/sw/subversion/obj/repoA/db/txn-current-lock': Resource deadlock
avoided
Then after a bit more delay the fouth completes.
I didn't expect the failed commit. On the other hand it appears to be
handled gracefully: the server keeps running and the client gets
notified.
Yes, we don't see any issues with the repository after a failed lock.
I think there's a deadlock because the kernel assumes that the process
is single threaded. It doesn't know that the other, non-blocked,
threads will make progress and release the lock.
Blair
