Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking

[Jan Hudec]

On Sun, Jun 06, 2004 at 12:30:16 -0700, Tom Lord wrote:
> 
>     > From: address@hidden (Julian T. J. Midgley)
> 
>     > >On Sat, May 29, 2004 at 02:14:39PM +0100, Andrew Suffield wrote:
>     >>> But if you want to support almost any other combinations of
>     >>> anything then you're screwed.
> 
>     >>Oh, and hint: it is not without good reason that expansions such as
>     >>"Network Failure Service", "No File is Safe", became popular.
> 
>     > I understood that 
> 
>     >  1. Create nonce file 
>     >  2. hardlink lock file to it
>     >  3. check reference count of nonce file 
> 
>     > Was a reliable way of locking files across NFS.  Is this not the case?
> 
> You could do just as well with only one system call:
> 
>       1. Rename lock file to nonce file.  If that
>            succeeds, you own the lock (at least at the
>            instant that the rename completes).

No. It does not work for files, because renaming file over another one
simply unlinks the old! (and does so atomicaly in a sense that there is
no window where the target does not exist). It does, however, work for
directories, since directories can't be unlinked.

> Unfortunately, that only gets you an advisory lock -- nothing enforces
> the lock.
> 
> Worse, that only gets you a _useless_ advisory lock -- nothing _can_
> enforce the lock.
> 
> Because locks are represented persistently, and because processes that
> make them have independent lifetimes, it is always possible that the
> lock will outlive your process.
> 
> That's fine.  No problem -- but it does mean you need a way to be able
> to _break_ a lock whose process has died.
> 
> It's impossible, in the general case, to be certain that a process
> you've heard about has actually died.   So, your decision to break a
> lock might be a mistaken one.
> 
> What is the upshot of all of that?   To actually be robust, your
> process will not only have to aquire a lock, it will have to be 
> able to handle the situation where somebody else breaks its lock
> while your process is still running.
> 
> Yet with link counts or renamed lock files -- your process can not
> ever be certain that its lock hasn't been broken.   It can check --
> but the possible outcomes are:

Yes. You are right.

But thinking of this, it is actualy impossible to do this to be tolerant
to every single possible failure. It can be tolerant to many, but never
all.

The solution used currently on arch archives can be viewed as
implementing transactions. If you can restate the problem in terms of
transactions, it should be possible to create a schema, using fancy
renaming, that will handle it.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature