🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.mail.misc
Article #3015

Re: Will ELM ever use lockf()?

#3015
From: Rahul Dhesi
Date: Wed, 17 Apr 1991 19:38
94 lines
3961 bytes
The usual technique for locking with a lock file, and storing the pid
in the file, has two problems.  One is the window such that two process
could find a dead lock file, and both could remove it and create their
own, with a race condition.  The other problem is that exclusive
creates do not work over NFS.  Solution follows.

Date:    22 Jan 91 07:41:25 GMT
From:    dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Newsgroups: comp.lang.perl
Subject: Re: Locking files across NFS
References: <1991Jan15.203815.25561@uvaarpa.Virginia.EDU>
Sender:  cirrusl!news
Organization: Cirrus Logic Inc.

In <1991Jan15.203815.25561@uvaarpa.Virginia.EDU> worley@compass.com
(Dale Worley) writes:

>Beware that Sun's locking daemons don't always work correctly.

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.

So the only reliable mechanism that exists to do file locking over NFS
is the following or its equivalent.  if you want reliable locking that
is reasonably immune to locks being held by dead processes, I see no
way of making this algorithm any simpler.

int get_a_lock()
{
     if (create(symlink called MUTEX that points anywhere) == failed) {
	die("serious problem -- can't create MUTEX");
     }
     /* reach here when gained exclusive access */
     attempts = 0;
     while (++attempts < SOME_LIMIT) {
	if (create(some unique temp file called $TMP) == succeeded) {
	   to $TEMP write our host name and pid;
	   break; /* done with while loop */
	} else {
	   sleep (a few seconds);
	}
      }
      if (attempts == SOME_LIMIT) {
	 die("serious problem -- can't create mutex");
      }
   try_again:
      {
        static int loop_breaker;
	if (++loop_breaker > SOME_OTHER_LIMIT) {
	   loop_breaker = 0;
	   unlink($TMP);
	   unlink(MUTEX);
	   return LOCK_ATTEMPT_FAILED; /* or die here */
	 }
      }
      if (create(link from $TMP to LOCK) == success) {
	 /* we have the lock!! */
	 unlink($TMP);  /* not needed, link is now LOCK */
	 unlink(MUTEX); /* not needed, done its work */
	 return GOT_A_LOCK;
      } 
      /* failed to create link;  see if it's a stray link */
      if (LOCK doesn't exist) {
	 unlink($TMP);
	 unlink(MUTEX);
	 die("serious problem, LOCK nonexistent but can't create");
      }
      if (read(contents of LOCK) == failed) {
	 unlink($TMP);
	 unlink(MUTEX);
	 die("serious problem, can't read existing LOCK");
      }
      lock_host = name of host read from LOCK;
      lock_pid = pid read from LOCK;
      if (lock_host is our current host) {
	 /* see if process still alive */
	 if (kill(pid, SIG_SEE_IF_IT'S_THERE) == ENO_SUCH_PROCESS) {
	    unlink(LOCK); /* must have been stray */
	    goto try_again;
	 } 
      }
      /* LOCK is already held by existing process on this host
      or is on some other host */
      return LOCK_ATTEMPT_FAILED;
}
--
Rahul Dhesi <dhesi@cirrus.COM>
UUCP:  oliveb!cirrusl!dhesi
Technical Details
Message-ID: <3064@cirrusl.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!tymix!cirrusl!ss168!dhesi
References: <27FA24B0.5244@tct.com> <UHPPYLW@geminix.in-berlin.de> <2800BA22.1CAE@tct.com> <1991Apr09.160512.1300@chinet.chi.il.us>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!tymix!cirrusl!ss168!dhesi
From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Newsgroups: comp.mail.misc
Subject: Re: Will ELM ever use lockf()?
Message-ID: <3064@cirrusl.UUCP>
Date: 17 Apr 91 19:38:47 GMT
References: <27FA24B0.5244@tct.com> <UHPPYLW@geminix.in-berlin.de> <2800BA22.1CAE@tct.com> <1991Apr09.160512.1300@chinet.chi.il.us>
Sender: news@cirrusl.UUCP
Reply-To: Rahul Dhesi <dhesi@cirrus.COM>
Lines: 94