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
