From: Shawn Pearce Date: Thu, 06 Jan 2011 16:48:11 GMT Subject: Re: Concurrent pushes updating the same ref Message-ID: In-Reply-To: <20110106163035.GA7812@sigill.intra.peff.net> On Thu, Jan 6, 2011 at 08:30, Jeff King wrote: > > Yeah, we probably should try again. The simplest possible (and untested) > patch is below. However, a few caveats: > >  1. This patch unconditionally retries for all lock files. Do all >     callers want that? I wonder if there are any exploratory lock >     acquisitions that would rather return immediately than have some >     delay. I don't see why not. We shouldn't be exploring to see if a lock is possible anywhere. >  2. The number of tries and sleep time are pulled out of a hat. FWIW, JGit has started to do some of this stuff for Windows. We're using 10 retries, with a delay of 100 milliseconds between each. This was also pulled out of a hat, but it seems to have resolved the bug reports that came in on Windows. We unfortunately have to do retries on directory and file deletion. >  3. Even with retries, I don't know if you will get the behavior you >     want. The lock procedure for refs is: > >        1. get the lock >        2. check and remember the sha1 >        3. release the lock Why are we locking the ref to read it? You can read a ref atomically without locking. >        4. do some long-running work (like the actual push) >        5. get the lock >        6. check that the sha1 is the same as the remembered one >        7. update the sha1 >        8. release the lock > >     Right now you are getting contention on the lock itself. But may >     you not also run afoul of step (6) above? That is, one push updates >     the ref from A to B, then the other one in attempting to go from A >     to B sees that it has already changed to B under our feet and >     complains? Not if its a force push. :-) -- Shawn.