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?
> Blair
Received on 2011-03-31 00:07:45 CEST