On 3/28/07, C. Michael Pilato <email@example.com> wrote:
> I just added the following comment to issue #2699 in response to the
> 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
Received on Wed Mar 28 21:13:11 2007