Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!unidui!unido!rwthinf!marvin.e17.physik.tu-muenchen.de!berg
From: berg@marvin.e17.physik.tu-muenchen.de (Stephen R. van den Berg)
Newsgroups: comp.mail.misc
Subject: Re: Will ELM ever use lockf()?
Message-ID: <4240@rwthinf.UUCP>
Date: 18 Apr 91 08:25:46 GMT
References: <2800BA22.1CAE@tct.com> <1991Apr09.160512.1300@chinet.chi.il.us> <3064@cirrusl.UUCP>
Sender: news@rwthinf.UUCP
Lines: 18

In article <3064@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes:
>Sun's locking daemons have never worked correctly whenever I have tried
>them.  I finally decided that it would be better to rely on the
>standard reliable UNIX method:  create a lock file.  I used this
>successfully for a while.  Then discovered with a shock that NFS has no
>mechanism for ensuring exclusive creation of a file even if the O_EXCL
>flag is given to open().  NFS does make symbolic links links correctly.
>I think it may even make hard links correctly.  The following algorithm
>assumes that hard links are correctly created atomically.

If hardlinks are assumed to be made correctly (which I suspect they are
indeed, why shouldn't they?), why are you then going through all this
trouble with the symlink (MUTEX)?   Why not use one hardlink to the lockfile?
--
Sincerely,                 berg@marvin.e17.physik.tu-muenchen.de
           Stephen R. van den Berg.
"I code it in 5 min, optimize it in 90 min, because it's so well optimized:
it runs in only 5 min.  Actually, most of the time I optimize programs."