branch locking mk2.

[Robert Collins]

On Wed, 2006-02-08 at 14:11 +0200, Nir Soffer wrote:

> I don't see how you can change the timeout after a caller got a lock. 
> The caller can safely assume he has a lock for the full timeout.

....
I think our lock designs are solving quite different problems. The
design I started this thread with is intended to work across the network
on exceeding dumb and unfriendly file systems, it requires few
properties of the file system (specifically it requires that renaming a
directory to a directory fails, and that renaming a directory is atomic,
and that files can be stored in directories and are moved when their
containing directory is renamed). Note that it does not require that
creating files or directories is atomic.

From what you say the moin locks are not applicable to our issues here
because:
 * we cannot kill other processes over the network, 
 * we cannot share instance variables with other lock holders
 * we cannot be sure that creating a directory can only succeed for one
caller.

The way the design [which has had no negative feedback yet, fingers
crossed] works is very similar to arch locks, a refinement on them
perhaps. One
 *  creates a directory with a probabilistically unique name (so
atomicity of create does not matter),
 * writes a data file inside the directory (atomicity does not matter as
competing lockers are not hostile and will not alter the inside of
directories that are not their own; if they were to want to gc pending
locks they would rename the dir before rmming to cause failures if the
locker was still active.)
 * peforms a rename of the directory to a known location, this will fail
on all platforms we know about if there is a destination file; its this
failure that we want and that makes the locking logic safe.

Unlocking is just done in reverse, but to a different temporary
location. 


All the gory details are back in my first email.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/7da458cb/attachment.pgp