Re: Concurrent pushes updating the same ref
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Jan 6, 2011, 16:48 UTC
- Message-ID
- <AANLkTinGYjExrnHCqcTPu-APzk9WynxwWoKVOLaSkZ2y@mail.gmail.com>
- In-Reply-To
- <20110106163035.GA7812@sigill.intra.peff.net>
On Thu, Jan 6, 2011 at 08:30, Jeff King <peff@peff.net> wrote:
Show 8 quoted lines
> > 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.
Show 6 quoted lines
> 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.
Show 11 quoted lines
> 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.