Re: EDEADLK in svn_repos_fs_begin_txn_for_commit2

Blair Zajac <blair_at_orcaware.com> writes:

> We're seeing deadlocks in our Subversion multithreaded server when two
> distinct processes try to fcntl(F_SETLKW) on two fsfs repositories'
> db/txn-current-lock, when the processes begin transactions in reverse
> order.
>
> Process 1 Process 2
> --------- ---------
> thread 1: begin txn in repos A thread 1: being txn in repos B
> thread 2: begin txn in repos B thread 2: begin txn in repos A
>
> During normal working hours, we get over 1 commit per second, peaking
> at 6, which is why we're seeing this.

It's not clear to me why that is a deadlock. When the second thread is
waiting why does the first thread not make progress? I can't reproduce
it on my Linux machine running Debian/stable.

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?

Are you on a platform with SVN_FS_FS__USE_LOCK_MUTEX set to 0 (Windows)
or 1? Without the mutex it might do:

  Process 1 Process 2
Thread 1 Thread 2 Thread 1 Thread 2
------------------- -------------------
Lock A Lock B
           Wait B Wait A
Unlock A
                                     Unlock B
                                                Lock A
           Lock B
           Unlock B
                                                Unlock A

If I include the mutex it might do:

  Process 1 Process 2
Thread 1 Thread 2 Thread 1 Thread 2
------------------- -------------------
Lock M1 Lock M2
Lock A Lock B
           Wait M1 Wait M2
Unlock A
Unlock M1
           Lock M1
           Wait B
                                     Unlock B
                                     Unlock M2
                                                Lock M2
                                                Lock A
           Lock B
           Unlock B
           Unlock M1
                                                Unlock A
                                                Unlock M2

Neither of those look like a deadlock.

-- 
Philip