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

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

"Baumgart, Jens" <jens.baumgart@xxxxxxx> wrote:
> in Bug 311051 a Branch operation failed due to parallel access to the GIT index file by 2 threads:
> 
> Thread 1: Git decorator reads the index using DirCache.readFrom
> Thread 2: BranchOperation fails in GitIndex.write because it cannot delete the index file
> 
> Bug 308506 seems to be a similar problem.
> 
> My question is: do we need synchronization for accessing the index file?
> One could e.g. think of introducing a read/write lock (ReadWriteLock) to protect access to the index file.

Yikes.

A reader shouldn't need to lock the index, its atomically updated
all-or-nothing on disk.  Except that on Windows you can't replace
the file while its being read.  Hmm.

An in-JVM read/write lock can help you work around this most of the
time, but only within this JVM process.  It won't do anything for
you when an external program is running `git status` at the same
time that Eclipse is updating the index file.

I wonder if we shouldn't try waiting a very short time on challenged
filesystems (*cough* Win32 *cough*) and try again inside of the
atomic write code paths.  Basically teach LockFile to wait and
retry the replacement every 200 ms for up to 2000 ms if the original
rename or delete fails on Win32.


I think I'm fine with adding some sort of read-write lock to
Repository to fairly serialize readers and writers of the index
file in memory and improve their chances of success when accessing
the file.  But I think we need to look at it from the more general
world-view and account for external processes interferring with
our own access too, hence the wait-retry suggestion above.

-- 
Shawn.