Although it is rare, there are times when a file may be open by multiple processes concurrently. If these processes have the file open solely for reading, everyone is more or less guaranteed to have an up to date copy of the file to read. However, when one or more processes is writing to the file, a complicated problem arises. In this scenario, readers must somehow detect that a change has been made and then get a copy of the updated information. A further complication occurs when changes are made by more than one writer at one time. In this case, the challenge is to coordinate changes made by the writers while at the same time giving accurate file snapshots to the readers! More complicated still is to synchronize changes among readers and writers when portions of the file are cached on each user's local system.

File Locking

The best solution to the problems posed by concurrent file access is to make sure that they can't occur in the first place. To this end, NFS includes a file locking feature called the lock manager. The lock manager and another process called the status monitor work together to guarantee that multiple readers and writers do not collide with each other. This is accomplished using file locking and access control mechanisms that are described below.

The lock manager provides UNIX style locking (otherwise known as advisory locking) between cooperating client and server processes, enabling synchronized access to files. The lock manager lets a process lock a file or part of a file for shared or exclusive access. When a process locks a file for exclusive access, no other process will be allowed to share the lock. When a process locks a file for shared access, other processes can share the lock but they will not be able to obtain an exclusive lock. If a process is denied access due to a conflict in lock type, it can optionally block until the lock is freed or it can return an error condition.

The status monitor provides the lock manager with information on host status. It monitors the system to ensure that locks will be handled properly if a system crashes while a file is locked. This is referred to as monitored locking. If the server crashes with monitored locks in place, the locks will be reinstated when the server recovers. Conversely, if the client crashes with monitored locks in place, the locks will be automatically freed by the server and must be reinstated by the client when it recovers.

Clients have the option of using lock manager without the status monitor in which case the locking is non-monitored. Non-monitored locking is provided for client systems that do not support multi-tasking and cannot run both lock manager and status monitor at the same time. In all other cases, monitored locking is preferred.

Cache Consistency and File Integrity

It is a common misconception that certain so-called cache consistency mechanisms can solve the problems of concurrent file access by multiple processes. Even complicated token passing schemes (discussed in the section entitled "Write Throughput Improvements" on page 13) cannot solve the problem alone. Two processes that wish to read and modify the same record of a file simultaneously will produce incorrect results if they don't use an explicit synchronization mechanism. For example, suppose the record in question is an account balance. If the balance is $1000 and the first process wishes to credit $150 and the second wishes to debit $200, the expected result is a balance of $950. If the processes fail to synchronize, then both will read a record of $1000, and depending on who finishes last, the balance will read $1150 or $800.

Therefore, in any case where fine grained control over concurrent file access is desired, the use of file locking technology is required.