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
