R. Clayton (rclayton@clayton.cs.monmouth.edu)
(no date)
"When lock() returns successfully, the caller has exclusive access to f until
the lock is released." This exclusive access is only as far as RFS is
concerned; others can access this file by other (non-RFS) means.
That's correct; you don't have to resort to unix file locking to solve this
(although you can if you want to).
The Locking mechanism has to be implemented at the Server to support locking
among clients, in which case we need to maintain state at the server. (the
only thing we can think of is using a file to maintain state information).
I'm not sure if this is a question, but I'll answer it anyway. The choice of
implementing a state-full or stateless server is up to you. We had a brief
discussion in class about whether the server could be stateless and came to
the conclusion that, because if file locking, it could not be. However, I've
been thinking about that since then, and - depending on how you wanted to
define "stateless server" - came to the conclusion that it might be possible
to implement a stateless, file-locking server using external storage.
However, you have to be careful about maintaining mapping information from a
client to external locked-files information (you also have to be careful about
crash recovery, but I'm not expecting you to take on that difficult subject in
this project).
We just want to make sure that what we design, does not turn out to be
too trivial or too complex.
Two of the most valuable properties of a design is that it be correct and
trivial. You should make sure your design is correct first, then worry about
complexity (but not its absence).
This archive was generated by hypermail 2.0b3 on Sun May 06 2001 - 20:30:05 EDT