gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking
Date: Sat, 5 Jun 2004 00:00:50 +0200
User-agent: Mutt/1.5.6i

On Fri, Jun 04, 2004 at 21:42:51 +0200, Sylvain Defresne wrote:
> Hello,
> 
> > The schema proposed is:
> >     1) Client creates a file with unique name on server. Retries as
> >        required.
> >     2) Client requests to link this file to the lockfile name. Retries
> >        until it gets a reply.
> >     3) Client IGNORES the reply, unless it is a permanent error
> >        (permissions, wrong path).
> 
> What if the two clients select the same random unique name (it may
> happen) and the NFS server does not honour the O_EXCL flag to open
> (somebody said that it is the case for linux 2.4) ? Won't the link call
> fails for one of the client with EEXIST error, and if they discard the
> error code, they will both think they have succeeded since the link
> count will be of two for the unique file ?

Who said they select a random one? They are better off using some
identity of the host they run on plust their pid.
(because O_EXCL is NOT supported on NFS -- that was already said here)

> >     4) Client stat's the temporary file it created in step 1. Retries as
> >        required.
> >     5) 
> >        - If the reply is 2, the lock is taken. Enters critical section.
> >        - If the reply is 1, someone else has the lock. Wait a short
> >      while and repeat from step 2.
> 
> I'm I wrong, or can this happens ? If yes, then the two process will
> enter the critical section at once, which can be bad ...

If they select the same random name, they screw up. But they should
select something they know the other client won't. If they do select
random numbers, sufficiently long ones will differ with reasonable
probability (ie. the probability is far less than the probability, that
the server will be destroyed by a meteor).

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]