branch locking mk2.

[Jan Hudec]

On Wed, Feb 08, 2006 at 11:16:05 +0200, Nir Soffer wrote:
> 
> On 8 Feb, 2006, at 3:25, Robert Collins wrote:
> 
> >Perhaps you could describe the differences between moins approach and
> >what I described ?
> 
> moin lock is based only on creating a directory, and does not assume 
> anything on rename, which is not atomic on Windows:
> 
> 	"On Windows, if dst already exists, OSError will be raised even if 
> 	it is a file; there may be no way to implement an atomic rename when dst 
> names an existing file."
> 	-- http://docs.python.org/lib/os-file-dir.html

Rename *IS* atomic on windows. Atomic means, in this case, it either
happens, or not, but nothing in the middle. If the dst already exists,
and is a directory (which is the case), directory rename never succeeds,
no matter what system.

The above refers to the fact, that *FILE* rename on POSIX atomically
replaces the destination. The proposal does NOT use that property.

> I'm not sure if this effect the solution you described, but its a 
> common error for posix users :-)

It's a common error for posix users to think windows are worse than they
actually are ;-).

> I'm not sure how your solution works, so I'll describe how moin 
> exclusive lock works, and some use issues.
> 
> Moin exclusive lock acquire a lock by creating a directory at a path, 
> and release the lock by removing the directory.
> 
> If the directory already exists, it goes into loop of trying to expire 
> the other lock (that created the directory) and create the directory 
> again, until the acquire timeout is reached, then it returns False.

Which fails over the network. Because over a network, it is possible to
get an error back even if you actually created the directory. So you
need a way to find out what actually happened on the server ex-post.
Therefore you must somehow mark the directory. Which can be done by
creating something inside it. But You can't do that atomically. So you
must do that beforehand.

> Expiring a lock is based on the modification time of the directory and 
> the timeout lock instance variable.
> 
> The write lock is a subclass that also try to remove read locks while 
> acquiring, which have smaller timeout.
> 
> Example usage:
> 	
> 	lock = WriteLock('/tmp/resource/lock', timeout=60)
> 
> 	if lock.acquire(10):
> 		try:
> 			# change the resource
> 		finally:
> 			lock.release()
> 
> If somehow you are left with a unused lock, the above lock will expire 
> only after 60 seconds. Killing a process is safe (I'm not sure kill -9 
> is).

No, it's not. It can't be for any lock not implemented by kernel itself.
Because when process gets SIGKILL, it is simply deleted, whithout a
chance to run even a single instruction. So it can't clean up anything,
except things cleaned up by kernel.

> It can be better to save information about the process holding the lock 
> in the lock directory, but its not easy,  because you can't create a 
> directory with a file atomically in a portable way.

Yes, you can. Create under unique name, place whatever content you need
and rename to destination.

> The design is little broken because you must create all locks for same 
> path with the same timeout. It can  be solved by creating the lock on 
> the resource, then return a shared lock. Many clients can reference  
> the same lock instance, only one of them can acquire the lock at a 
> time.
> 
> 	lock = branch.shared_lock() # return a lock using the branch timeout
> 
> The resource lock timeout must be shared between different processes 
> that try to acquire a lock on the same resource, and must not change 
> while the resource is locked.

Except it will change.

Actually it is important to note that the lock does not actually lock
anything! It is rather something like 'Please, please, wait a little
until I finish what I am doing' -- any other client *can* break your
lock anytime and it still must not result in a corrupted branch.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/3557cb59/attachment.pgp