On 03/30/2011 03:06 PM, Daniel Shahaf wrote:
> Blair Zajac wrote on Wed, Mar 30, 2011 at 13:59:30 -0700:
>> On 03/30/2011 04:00 AM, Daniel Shahaf wrote:
>>> Philip Martin wrote on Wed, Mar 30, 2011 at 10:33:42 +0100:
>>>> 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.
>>
>
> In other words, the difference between theory and practice is that the
> Linux kernel doesn't behave as theory predicts :-)
>
> Fair enough, thanks for the explanations. I'll go and add my +1 to the
> STATUS entry.
>
> I notice that FILE_LOCK_RETRY_LOOP() checks for EINTR when EDEADLK isn't
> defined (or when APR isn't threaded). I assume that check is there for
> the same reason --- i.e., that EINTR is another symptom of the deadlock
> situation that FILE_LOCK_RETRY_LOOP() was added due to?
No, that's unrelated. While I was working on the function, I decided to
handle EINTR in the same way that many of our other io functions do,
e.g. svn_io_create_unique_link(), svn_io_read_link(),
do_io_file_wrapper_cleanup(). This one didn't seem to hurt and makes
the function more robust. I didn't want spurious EINTR errors when
trying to get a lock.
Blair
Received on 2011-03-31 00:13:43 CEST