Re: Concurrent pushes updating the same ref

[Shawn Pearce <spearce@spearce.org>]

On Thu, Jan 6, 2011 at 08:30, Jeff King <peff@peff.net> 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.