Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.shell
Subject: Re: Creating a lock file in csh?
Message-ID: <1991Apr17.102654.4476@athena.mit.edu>
Date: 17 Apr 91 10:26:54 GMT
References: <1991Apr15.205654.26253@unhd.unh.edu> <1991Apr16.175347.1082@odin.corp.sgi.com>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 62

In article <1991Apr16.175347.1082@odin.corp.sgi.com>, rhartman@thestepchild.sgi.com (Robert Hartman) writes:
 1|> 	set noclobber
 2|> 	(echo "${user}: $$ `date`" > $file.lock) >& /dev/null
 3|> 	if ($status == 0) then
 4|> 	    if ($$ == "`awk '{ print $2 }' $file.lock`") then
 5|>         	# enter critical section
 6|>         	# ...
 7|> 	        # exit critical section
 8|> 	    else
 9|> 	        echo "$file in use by `cat $file.lock`"
10|> 	        exit 1
11|> 	    endif
12|> 	else
13|> 	    echo "$file in use by `cat $file.lock`"
14|> 	    exit 1
15|> 	endif
16|> 	unset noclobber
|> 
|> Can't see how NFS could matter here.

Let's assume that two processes are trying to get a lock in this way at
the same time over NFS.  There is no way in the NFS protocol to open a file
for write if it does not exist in an atomic operation.  Therefore, NFS client
kernels first have to check with the server to see if the file exists, and
send a request to create it if it doesn't.  So here's what could happen:

  1) Process A and Process B ask the NFS server if the file exists, at about
the same time, at line 2 above.

  2) Because they both ask at the same time, before either of them has time to
create the file, the NFS server tells both of them that the file doesn't
exist.

  3) They then both send requests to the server to create and write to the
file.  All of their requests are received and carried out, although the order
is completely race-dependent.

  4) Process A manages to write to the file and read it back at line 4 before
Process B's write requests to the server are carried out.  So Process A thinks
it has the lock and does the critical code.

  5) A very little while later, Process B's write request goes through, and
then it reads at line 4 and discovers that it has the lock, and does the
critical code.

  So, as you can see, both processes are doing the critical code at the same
time.  That's why NFS "could matter here."  The only way to do locks under NFS
is to use an NFS lock manager (gag choke wheeze).

  You're even more likely to get into race conditions with multiple processes
thinking they hold the lock if you remove lines 4 and 8-11 as you suggested
when you said:

|> The nested if double-checks to make sure
|> that the current process actually holds the lock.  This is probably
|> overkill, but it's easy enough to comment out or delete.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710