[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: the retry loop in svn_io_file_lock2()

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 31 Mar 2011 00:06:08 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.