RE: Git for games working group

["Randall S. Becker" <rsbecker@nexbridge.com>]

On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > >   2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > >      together." This isn't possible in Git LFS today with the existing
"git
> > >      lfs lock" command (I had to check, but it takes only _one_
filename as
> > >      its argument).
> > >
> > >      Perhaps it would be nice to support something like this someday
in
> > >      Git LFS, but I think we would have to reimagine how this would
look
> > >      in your file.lock scheme.
> >
> > If you can do it for 1 file you can do it for N with a for-loop, no?
> > So is this just a genreal UI issue in git-annex where some commands
> > don't take lists of filenames (or git pathspecs) to operate on, or a
> > more general issue with locking?
> 
> I think that it's more general.
> 
> I envision a scenario where between iterations of the for-loop, another
> client acquires a lock later on in the list. I think that the general
problem here
> is that there is no transactional way to express "please give me all N of
these
> locks".

A composite mutex is better, constructing a long name of X+Y+Z.lock and
obtaining the lock of that, then attempting all locks X.lock,Y.lock,Z.lock
and if any fail, free up what you did. Otherwise you run into a potential
mutex conflict if someone attempts the locks in a different order. Not
perfect, but it prevents two from going after the same set of resources, if
that set is common. Another pattern is to have a very temporary dir.lock
that is active while locks are being grabbed within a subtree, then released
when all locks are acquired or fail (so very short time). This second
pattern should generally work no matter what combination of locks are
required, although single threads lock acquisition - which is probably a
good thing functionally, but slower operationally.

Cheers,
Randall