On 01/26/2011 05:21 AM, Philip Martin wrote:
> Philip Martin<philip.martin_at_wandisco.com> writes:
>
>> Philip Martin<philip.martin_at_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
Received on 2011-01-26 19:28:51 CET