Blair Zajac <bl...@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
