Matt Benjamin wrote:
| The existing model works today but suffers from the failure to know that | the reason a callback was received was because the lock was dropped or | because a Store occurred etc. |> I believe there is a race between A (who received EWOULDBLOCK, and has decided to re-try) and B, who requests an overlapping lock, in the interval between C's release of the contended lock (3) and A's re-execution of its lock request (1).
This is not a race. The EWOULDBLOCK is an indication that the lock request failed because the lock is not available. This is identical to the existing implementation. The callback notification that the lock was dropped is just that. A notification. If the cache manager does not carethat is fine. If it still has a pending lock request it will retry. If the lock
is not available at the time of the retry, it will receive EWOULDBLOCKagain.
This is no different than performing a broadcast wake to a number of threads blocked on the same event object. There is no complicated logic here to deal with allocations that a client no longer wants or to deal with clients that are no longeron the network.
This behavior is 100% compatible with the expectations of the existing locking RPCs because it is the behavior of the existing locking RPCs. That being said. This approach permits byte range lock requests to be added with a minimum of changes to the file server and the cache managers and is a perfectly reasonable incremental step that can be implemented soon after the more informative callback notification messages are added because the changes do not require modifications to the state machine in either party. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
