Re: Issue 2699: Atomic multi-path locks (in FSFS)

On 3/28/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>
> I just added the following comment to issue #2699 in response to the
> problem
> of trying to allow atomic locking of multiple paths:
>
> I wonder (aloud) ... since locks are sorta outside the flow of normal
> versioned data, would it make sense to use a different mutex file in
> FSFS for lock/unlock operations? That way lockers/unlockers could
> block other lockers/unlockers, but not committers.
>
> It's not a well-baked idea, I admit. But can others offer any immediate
> thoughts on the idea? Ignoring compat issues, are there glaring problems?

Will be important that on a commit, when locks are released, that this
happens after the commit it complete?

What about prior clients where they directly touch the repository (file:
access)? When in client/server behavior, it is much easier to change around
locking files and what process uses them.

The good thing about separate locks is that this can be done (and I think
would be a good thing, especially since one can commit without releasing the
lock). However, the moment you get multiple mutexes or semaphores you must
make sure that any/all uses are of the exact same nesting order.

I think this change is "easy" in the case of client/server constructs. It
is much harder in the file: access methods. (Deadly embrace could be caused
due to a badly written client)

-- 
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz