The locking protocol
There are four basic kernel-to-lock manager (KLM) requests:
Despite the fact that the network lock manager adheres to the
lockf and fcntl semantics, there are a few subtle
points about its behavior that deserve mention. These arise directly
from the nature of the network:
Lock the specified record.
Unlock the specified record.
Test if the specified record is locked.
Cancel an outstanding lock request.
For more information about UnixWare locking, see
The lock manager plays an important role during system crashes. When
an NFS client goes down, the lock managers on all servers are notified
through their status monitors. The servers then release the client's
locks, on the assumption that the client will request locks again as
needed. When a server crashes, clients wait for the server to come back
up. Once the server is up, its lock manager will give the client lock
managers a grace period to submit lock reclaim requests; during this
period, the server will accept only reclaim requests. The client status
monitors will notify their respective lock managers when the server
recovers. The default grace period is 45 seconds.
It is possible that, after a server crash, a client will not be able to
recover a lock that it had on a file on that server because another
process may have beaten the recovering application process to the lock.
In this case, the SIGLOST signal will be sent to the process
(the default action for this signal is to kill the application).
The local lock manager does not reply to the kernel lock request until
the server lock manager has responded to it. Further, if the lock request
is on a server new to the local lock manager, the lock manager registers
its interest in that server with the local status monitor and waits
for its reply. Thus, if either the status monitor or the server's lock
manager is unavailable, the reply to a lock request for remote data is
delayed until it becomes available.
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004