Re: [egit-dev] Concurrent access to Git Index - synchronization required

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

Christian Halstrick <christian.halstrick@xxxxxxxxx> wrote:
> I think it is crucial that we don't force anybody to use jgit with
> such synchronization code.

Right.

Index updates are atomic.  So the only problem is on Windows.

On Windows, two concurrent readers of the same index are fine.
It should just work without errors or any additional logic as they
are all opening the same file in read-only mode.

If there are two concurrent writers on any platform, only one will
get the lock, and the other will fail.  This is also reasonable,
the other writer throws an exception.  The caller should either
report that up higher, or backoff and retry.  This strategy will
work even if the concurrent writers are in different processes and
possibly even different implementations (e.g. msysgit and JGit).

If there is a concurrent reader and a concurrent writer, the reader
can read at the same time as the writer.  However an active reader
may block the writer from being able to commit, because the writer
can't rename over top of the open file.  In such cases on Windows
the writer should backoff and retry a few times before declaring
an exception.  Again, this strategy would work well even if msysgit
was the concurrent reader.

We shouldn't need locks inside of the JVM.  Index reading or writing
doesn't take that long.  Backing off for some small amount of time
like 75 ms and retrying the operation a couple of times, up to a
maximum of 500 ms or some reasonable upper limit, would be just fine.

The only place where we really run into contention problems is
a writer trying to do the atomic rename while the index is open
for reading.  We just have to back off long enough for the readers
to exit.  If the readers keep firing and blocking the writer,
there isn't much we can do.  The readers are poorly tuned if they
keep reading the index file multiple times per second.

-- 
Shawn.