On 03/30/2011 04:00 AM, Daniel Shahaf wrote:
> Philip Martin wrote on Wed, Mar 30, 2011 at 10:33:42 +0100:
>> Daniel Shahaf<d.s_at_daniel.shahaf.name> writes:
>>
>>> Why does svn_io_file_lock2() have a retry loop?
>>>
>>> The reason given in the code is that some consumer of libsvn_fs wants to run
>>> a critical section while holding a lock in each of two FSFS filesystems. In
>>> that case, why isn't the fix just to tell the consumer to, when wanting to
>>> lock N filesystems, to always lock them in a well-defined order?
Hey Daniel,
I put the retry code in to handle a case we were seeing.
In our case, the client is some arbitrary code that is making calls to
an asset management system, which happens to be backed by svn, and we
have no control over the client.
Each client only gets a lock in a single repository, but because the
server is multithreaded, the process may have multiple locks taken
simultaneously, in random order.
>> First, the knowledge about the locks is entirely within the thread at
>> present, each thread has no knowledge of what other threads are doing.
>
> But if the threads are independent, why are you describing the situation
> as deadlock? With independent threads, p1t1 and p2t1 should finish
> their business and unlock both A and B, independently of anyone else who
> may have tried to lock either A or B...
I agree with your assessment, which was mine also, but it appears that
the Linux kernel does not know that each thread will make progress on
its own, and I'm guessing that it cannot assume that the thread will
make progress. It seems that the kernel treats the process as a single
threaded process, which then means a deadlock has occurred for the
scenario outlined in the code.
Blair
Received on 2011-03-30 23:00:09 CEST