I received two, similar, answers on the question of locking files within
AFS (sorry John, I did mis-read your note)
1)
-----------------------------------------------------------------------------
----------------------
Excerpts from ext.misc.info-afs: 29-Oct-92 Re: Write Lock and AFS John
Gardiner Myers@cmu. (516)
> In order to guarantee cache consistency you generally want to obtain
> the write lock before opening the file you want to modify.
> The best way to do this is to lock a different file than the one
> you're trying to modify. Most of the code I have seen/written that
> locks files in AFS work like this:
> * open lock file (O_RDONLY | O_CREAT)
> * while lock attempt fails (EWOULDBLOCK)
> * give up if too many tries
> * wait
> * open data file
> * modify data file
> * close data file
> * release lock & close lock file
> _.John
2)
-----------------------------------------------------------------------------
----------------------
Excerpts from ext.misc.info-afs: 29-Oct-92 Re: Write Lock and AFS
[EMAIL PROTECTED] (2432)
> There is still a race between open and lock, but it's not as big.
> Somebody else could get a lock,append,close in there on you.
> I think you have to do something more like:
> fd1 = open (READ) -- can't be RDWR because of AFS consistency semantics
> flock(fd1, EXCLUSIVE) -- so nobody else can write it
> fd2 = open (RDWR)
> append(fd2, some stuff)
> close(fd2);
> flock(fd1, UNLOCK)
close(fd1);
-------------------------------------------------------------------------------
-------------------------
They are similar in that they both open two file descriptor, one to lock
and the other to write the file. They are different in that John's
opens a different file, where Lyles opens the same file.
I implemented Lyles method and it work's great. However, upon analyzing
the results of my stress test further, I notice that the lock collisions
occur quite a bit more frequently. I expected this, but it does raise a
question:
Does the OPEN operation read in the whole file before it returns? If
so, would I end up reading in the file twice?
I may want to implement John's method, because the file can get fairly
huge, and the lock file could be a zero length file. Thus, opening the
lock file would be a fast operation instead of another slow open on the
same huge file.
Any thoughts?
Kris Davis ([EMAIL PROTECTED], krisd@rchland, krisd@rchvmw2)
Microcode Development Environment Dept213
1-507-253-3707 IBM Rochester, MN
