Synchronization using commitment
A method of sharing a file object among a plurality of competing processes, the file object having a content that at least one competing process may need to adjust so that the file is suitable for the operating environment of the competing process. To help make an adjustment, the file object includes a state attribute that indicates whether or not the file is committed and whether the file is in an inconsistent state. If the file contents are suitable for the specific process and the file object is not committed, the file can be committed by the specific process. If the file contents are not suitable for the specific process and the file object is not committed, the file is locked, set to inconsistent, adjusted, committed by the specific process and then unlocked. This process improves concurrency of the competing processes and reduces message overhead.
Latest Hewlett Packard Patents:
Field of the Invention
The present invention relates generally to a loosely-coupled multi-processor system that shares a commonly-used file, and it more particularly relates to processes that execute on each of the processors of the multi-processor system; the invention reduces the message traffic among the processors needed to achieve a single, consistent image of the commonly-used file.
DESCRIPTION OF THE RELATED ARTFile objects, such as executables and library object files, that are requested by the client processes generally contain references that may need to be adjusted when the file object is downloaded on a particular client system so that it properly references other library files, possibly of a different version, on that client system. These references must be written into the contents of the file object and the adjustment must be synchronized with the other client systems so that the file object contents remains consistent. This means that each client process 42-46 that uses the file object must determine whether the contents of a file object are properly adjusted for the process environment that the file object will encounter on the particular client system 10-14. If a file object is currently loaded and in use by any client process, it cannot be changed, but is sharable as long as the other sharing client processes can use the file object with its current adjustments. It is necessary to have a protocol to determine when the current adjustments are appropriate and preserve that state, and to deal with the case in which a client process must adjust the contents of a file object for proper use within its processing environment
A protocol for achieving such a modification that is consistent with the processing requirements of processes on the other client systems is shown in
The first event 104 depicted in
Though the above protocol is effective at maintaining the consistency of the shared file among the competing processes of the client systems, it is expensive in terms of the messages that are required to be sent to and from the disk process. Two messages, a lock and an unlock, are required by each competing process to determine whether the file is in proper condition for use by that process, regardless of whether or not the file contents must be adjusted. The protocol is also expensive in terms of the lack of concurrency that such a process causes to the competing processes because each process must lock the file in order to determine whether an adjustment is required. This does not permit any other process access to the file to determine if the condition of the file is proper for the other processes. If the process cannot obtain the lock because another process has the lock, it must wait for the lock to be released before it can even examine the file.
Therefore, there is a need for an improved protocol that reduces the message traffic to and from the disk process and improves the concurrency among the several client processes.
BRIEF SUMMARY OF THE INVENTIONThe present invention is directed towards the above need. It provides a method for sharing among a plurality of competing processes a file object that includes file contents and a state that describes whether the file contents are inconsistent and whether the file object is in the use of a competing process. The state has a value that is either ‘uncommitted’, ‘inconsistent’ or ‘committed’. The method includes determining the state value of the file object and whether or not the file content is suitable for use by a specific one of the competing processes. If the state value of the file object is not ‘committed’ and either the state value is ‘inconsistent’ or the file content is not suitable for use by the specific one of the competing processes, the method then obtains exclusive access to the file object, adjusts the contents of the file object, sets the state of the file object to ‘committed’, and relinquishes exclusive access to the file object. If the state value of the file object is not ‘committed’ and the state value is not ‘inconsistent’ and the file content is suitable for use by the specific one of the competing processes, the method sets the state of the file object to ‘committed’. If the state value of the file object is ‘committed’ and the file content is suitable for use by the specific process, the method shares the committed file; otherwise, the method returns a failure status.
One advantage of the present invention is that the message traffic is greatly reduced from two messages for each check of the shared file to either none or one message in the most common cases. One message is needed if the state value of the file object is ‘uncommitted’ and its contents are suitable for use. No message is needed is if the state value of the file object is ‘committed’ and the file content is suitable for shared use by the specific process. Only when the file must be adjusted are more messages required. However, that case occurs rarely.
Another advantage is that the client processes can each operate with a greater degree of concurrency because each of the client processes has access to the shared file without a lock being required in order to determine whether the file contents are suitable for use. In most cases the file is in the proper condition for that client process and needs no adjustment, which means that no locks are required and a process can continue its execution of the shared file without delay.
These and other features, aspects and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:
The ‘uncommitted’ state value means that the file object is not in use by any client process. If the file object is undergoing modification, the state is temporarily set to ‘inconsistent’, which means that the file may have been partially altered. Once the file content has been accepted by a client, the state is set to ‘committed’. When no client is using the file object, its state reverts to ‘uncommitted’.
Returning to
In
In the first case, if the state value of the file object is ‘committed’, as determined in step 122, and the file contents are in proper form for use by the specific client process as determined in step 124, then a success indication is returned. This means that no adjustment of the file object contents was required and the file object can be shared by the specific client process.
In the second case, if the state value of the file object is ‘committed’, as determined in step 122, and the file contents are not in proper form for use by the specific client process as determined in step 124, then a failure indication is returned.
In the third case, if the state value of the file object is not ‘committed’, as determined in step 122, and the state value of the file object is not ‘inconsistent’ and its contents are suitable for use, as determined in step 126, the specific client process makes an attempt to commit the file. To do this, the client process performs a CommitIfUncommitted operation in step 128. Upon receiving a reply from the disk process that the file object is committed, the flow terminates with a success indication.
In the fourth case, if the state value of the file object is not ‘committed’, as determined in step 122, and either the state value is ‘inconsistent’ or the file object's contents are not suitable for use, as determined in step 126, the specific client process attempts to lock the file by performing a LockUnlessCommitted operation in step 130. This operation entails sending a LockUnlessCommitted request to the disk process and receiving a reply that an exclusive lock has been granted from the disk process in response to the message. Following this, a SetInconsistent operation is performed in step 132, which sets the state of the file object to ‘inconsistent’, and the contents of the file object are adjusted in step 134. Finally, a CommitAndUnlock operation is performed in step 136. This operation commits the adjusted file and releases the exclusive lock on the file object.
It can be observed that the protocol of the present invention, then, only locks a file object if the file object must be adjusted (the fourth case above). It does not lock the file object to determine whether the contents of the file object are suitable for use by the client process. Therefore, if the most commonly occurring case is that the file object needs no adjustment, then a lock and unlock message to the disk process are saved and only a CommitIfUncommitted message is needed (the third case above). If the file object is already committed, no message is required and two messages are saved (the first and second cases above). Thus, either one or two messages are saved by the protocol of the present invention and the concurrency of each of the competing processes is improved because no lock is required to determine the condition of the shared file.
First, in step 140, the client process sends a LockUnlessCommitted request to the disk process. In the disk process, at step 141, if the file is locked, the request stays pending until the file is unlocked. The disk process then ascertains, in step 142, the current state of the file object, which can be any one of the three states.
If the state value of the file object is ‘uncommitted’, the disk process locks the file for the specific client process, in step 144, and replies back to the client process indicating that the file object's state is ‘uncommitted,’ in step 145. The process then continues at step 132 of
If the state value of the file object is ‘inconsistent’, the disk process locks the file for the specific client process, in step 146, and then replies back to the client process indicating that the state value of the file object is ‘inconsistent,’ in step 147. In response to receiving this reply, the client process re-reads the contents of the file object, in step 148, and the flow continues at A in
If the state value of the file object is ‘committed’, the disk process replies back to the client process indicating that the file object's state is ‘committed’. This prompts the client process, upon receipt, to re-read the contents of the file object, in step 150. The flow then continues at C in
In step 160, the specific client process sends a CommitIfUncommitted Request to the disk process. In the disk process at step 161, if the file is locked, the request stays pending until the file is unlocked. The disk process then ascertains, in step 162, the current state value of the file object, which can be any one of the three states.
If the state value of the file object is ‘uncommitted,’ the state value is set to ‘committed’ in step 164, and the disk process sends a reply back to the specific client process indicating success, in step 165. The return path in
If the state value of the file object is ‘inconsistent,’ the disk process sends a reply back to the specific client process so indicating, in step 163, and the flow continues at B in
If the state of the file object is ‘committed,’ the disk process sends a reply back to the specific client process so indicating, in step 162, and this prompts the client process to re-read the contents of the file object in step 166. The process continues at C in
The protocol of the present invention requires the following conventions. First, while the state value of a file object is ‘committed’, it cannot be changed. Second, the contents of a file object can only be changed when it is locked. Third, while the state value of a file object is ‘uncommitted’, the contents of the file object are not altered. These conventions allow the sharing of the file object by multiple processes without a lock to determine whether the contents of the file object are suitable for use without adjustment. This sharing, in turn, permits a greater degree of concurrency among the processes competing for the file object and cuts down on message traffic because a lock is not required to determine the suitability of a file object for a specific client process.
The race occurs as follows. In
In an alternative version of the invention, the disk process tracks, for each client, whether the contents of the file object have been written or adjusted after a client process opened the file object, and if not, then replies, in step 234 of
The first event in
The first event in
Meanwhile, client A requests a CommitIfUncommitted operation in step 272, and waits for the reply. The request is held by the disk process because of the lock obtained by client B on the file object, which delays the state value of the file object from being available to other client processes.
As mentioned above, client B performed a LockUnlessCommitted operation in step 268. The disk process replied with a grant of the lock in step 270 and client B then responded with a SetInconsistent message in step 276 back to the disk process. At this point client B has exclusive ownership of the file object and is free to adjust the contents of the file object, in step 278, to meet its operating conditions. Following adjustments to the file object's contents, client B performs a CommitAndUnlock operation in step 280. Once the file object is unlocked by client B, the disk process replies to the waiting client process A in step 274. Only then does client A discover that the state value of the file object is ‘committed’. This causes client process A to request a re-read of the contents of the file object to determine if the altered file object is suitable for its use.
The first event is, as usual, an open request in step 290 by client B. The disk process replies in step 300 with the Open ID, the state value of the file object (‘uncommitted’) and the requested file object contents. The second event is an open request from client process A in step 302 which returns the same information in step 304. Now, because both processes need to alter the contents of the file object, there is a race to lock the file object by performing a LockUnlessCommitted operation. In the figure, client process B performs the LockUnlessCommitted operation, in step 306, and the disk process responds by replying that the lock is granted to client B in step 308. Client A then performs a LockUnlessCommitted operation in step 310 but does not receive an immediate response. The delay in receiving the response occurs because the file object is locked and undergoing an adjustment by client B. After Client B performs a SetInconsistent operation in step 312 and adjusts the file object contents in step 314, client B then performs a CommitAndUnlock operation in step 316. The unlocked condition of the file object causes client A to discover that the state value of the file object is ‘committed’, in step 318 and to request a re-read to determine whether the changed file is now suitable for use of the file in client A's environment. If so, client A can share the file.
Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.
Claims
1. A method for sharing among a plurality of competing processes a file object that includes file contents and a state that describes whether the file contents are inconsistent and whether the file object is in the use of a competing process, the state having a value being selected from a group consisting of ‘uncommitted’, ‘inconsistent’ and ‘committed’, the method comprising:
- determining the state value of the file object and whether or not the file content is suitable for use by a specific one of the competing processes;
- (i) if the state value of the file object is not ‘committed’ and either the state value is ‘inconsistent’ or the file content is not suitable for use by the specific one of the competing processes: obtaining exclusive access to the file object; adjusting the contents of the file object; setting the state of the file object to ‘committed’; and relinquishing exclusive access to the file object;
- (ii) if the state value of the file object is not ‘committed’ and the state value is not ‘inconsistent’ and the file content is suitable for use by the specific one of the competing processes, setting the state of the file object to ‘committed’;
- (iii) if the state value of the file object is ‘committed’ and the file content is suitable for use by the specific process, sharing the committed file; and
- (iv) otherwise, returning a failure status.
2. A method as recited in claim 1, further comprising the steps of:
- setting the state value of the file object to ‘inconsistent’ after obtaining exclusive access to the file object; and
- if the specific process fails while having exclusive access to the file object, relinquishing exclusive access to the file object to leave the state value of the file object as ‘inconsistent’.
3. A method for sharing among a plurality of competing processes a file object that includes file contents and a state that describes whether the file contents are inconsistent and whether the file object is in the use of a competing process, the state having a value being selected from a group consisting of ‘uncommitted’, ‘inconsistent’ and ‘committed’, the method comprising:
- (a) opening and reading the file object to determine the state value of the file object and whether or not the contents of the file object are suitable for use by a specific one of the competing processes; (i) if the state value of the file object is not ‘committed’ and either the state value is ‘inconsistent’ or the file content is not suitable for use by the specific one of the competing processes:
- (b) performing a LockUnlessCommitted operation;
- (c) upon receiving a lock on the file, performing a SetInconsistent operation;
- (d) adjusting the contents of the file object;
- (e) performing a CommitAndUnlock operation to commit and unlock the file object; and
- (f) returning a success indication; (ii) if the state value of the file object is not ‘committed’ and the state value is not ‘inconsistent’ and the file content is suitable for use by the specific one of the competing processes':
- (g) performing a CommitIfUncommitted operation on the file object to commit the file object; and
- (h) upon receiving an indication that the file object is ‘committed’, returning a success indication; and (iii) if the state value of the file object is ‘committed’:
- (j) if the content is suitable, sharing the committed file; and
- (k) if the content is not suitable, returning a failure indication.
4. A method as recited in claim 3, wherein the step of performing a LockUnlessCommitted operation includes:
- (n) requesting a lock on the file object;
- (m) ascertaining the state value of the file object; (iv) if the state value of the file object is ‘uncommitted’:
- (o) locking the file object; and
- (p) replying to the specific one of the client processes that the state value of the file object is ‘uncommitted’; (v) if the state value of the file object is ‘inconsistent’:
- (q) locking the file object;
- (r) replying to the specific one of the client processes that the state value of the file object is ‘inconsistent’;
- (s) re-reading the contents of the file object; and
- (t) continuing at step (d); and (vi) if the state value of the file object is ‘committed’:
- (u) replying to the specific one of the client processes that the state value of the file object is ‘inconsistent’;
- (w) re-reading the contents of the file object;
- (x) if the contents are suitable, sharing the file object and returning a success indication; and
- (y) if the contents are not suitable, returning a failure indication.
5. A method as recited in claim 4, wherein the step (m) of ascertaining the state value of the file object includes the steps of:
- determining whether the file object is locked;
- if the file object is locked, waiting until the file object is unlocked; and
- if the file object is not locked, determining the state value of the file object.
6. A method as recited in claim 4, wherein step (n) is performed by the specific client process.
7. A method as recited in claim 4, wherein steps (m), (o), (p), (q), (r), and (u) are each performed by a disk process.
8. A method as recited in claim 4, wherein steps (s) and (w) are each performed by the specific client process.
9. A method as recited in claim 3, wherein the step of performing a CommitIfUncommited operation on the file object includes the steps of:
- (n) requesting to change the state value of the file to ‘committed’;
- (m) ascertaining the state value of the file object; (iv) if the state value of the file object is ‘uncommitted’:
- (o) setting the state value of the file to ‘committed’; and
- (p) replying to the specific one of the client processes with a success status; (v) if the state value of the file object is ‘committed’:
- (q) replying to the specific one of the client processes that the state value of the file object is ‘committed’;
- (r) re-reading the contents of the file object; and
- (s) continuing at step (j); and (vi) if the state value of the file object is ‘inconsistent’:
- (t) replying to the specific one of the client processes that the state value of the file object is ‘inconsistent’; and
- (u) continuing at step (b).
10. A method as recited in claim 9, wherein step (n) is performed by the specific client process.
11. A method as recited in claim 9, wherein steps (m), (o), (p), (q), and (t) are each performed by a disk process.
12. A method as recited in claim 9, wherein step (r) is performed by a disk process.
13. A method as recited in claim 9, wherein the step (m) of ascertaining the state value of the file object includes the steps of:
- determining whether the file object is locked;
- if the file object is locked, waiting until the file object is unlocked; and
- if the file object is not locked, determining the state value of the file object.
14. A method as recited in claim 3, wherein the step of performing a CommitAndUnlock operation includes:
- (n) setting the state value of the file object to ‘committed’; and
- (m) releasing the lock on the file object.
15. A method as recited in claim 3, wherein the step of performing a SetInconsistent operation includes the step of (n) setting the state value of the file object to ‘inconsistent’.
16. A processing system, comprising:
- a processor; and
- an I/O subsystem coupled to the processor and adapted to couple to another system on which an object is stored, the object having an associated state and data contents;
- wherein the processor retrieves the object through the I/O subsystem, examines the object without using a lock and determines the state of the object;
- wherein, if the processor determines the state to be a first state in which the data contents have been accepted for use and are suitable for the processing system, the processor returns a success indicator; or
- wherein, if the processor determines the state not to be the first state nor a second state indicative of the data contents being modified, and determines the contents to be suitable for the processing system, the processor requests the system on which the object is stored to transition the state of the object to the first state.
17. The processing system of claim 16 wherein, if the processor determines the state to be the first state, but that the data contents are not suitable for the processing system, the processor returns a failure indicator.
18. The processing system of claim 16 wherein, if the processor determines the state not to be the first state and determines either that the data contents are not suitable for the processing system or that the state is not the second state, the processor requests the system on which the object is stored to lock the object, changes the data contents and requests the object to be unlocked.
19. A system, comprising:
- a processor; and
- an I/O subsystem coupled to the processor and adapted to couple to another system on which an object is stored, the object having an associated state and data contents;
- wherein the processor retrieves the object through the I/O subsystem, reads the object without using a lock and determines the state of the object; and
- wherein, if the processor determines the object is already in use by another system, the processor determines whether the data contents are suitable for use; and
- if the processor determines that the object is not already in use by another system and determines that the data contents are suitable for use and not being modified, the processor requests the object to be committed to indicate that the processing system has accepted the object; or
- if the processor determines that the object is not being used by another system and that the data contents are not suitable for use, the processor requests the object to be locked and then modifies the object's data contents.
20. The system of claim 19 wherein, if the processor determines the object is already in use by another system and determines that the data contents are suitable for use, the processor returns a success indication.
21. The system of claim 19 wherein, if the processor determines the object is already in use by another system and determines that the data contents are not suitable for use, the processor returns a failure indication.
22. A processing system, comprising:
- means for retrieving a file object having a configurable state and data contents;
- means for reading the file object without locking the file object;
- means for determining whether the file object is in use by another processing system;
- means for determining whether the data contents are suitable for use by the processing system if the object is already in use by another processing system; and
- means for committing the file object if the file object is not already in use by another processing system and if the data contents are suitable.
23. The processing system of claim 22 further comprising means for requesting the object to be locked and for modifying the data contents if the file object is not being used by another processing system and the data contents are not suitable.
6064382 | May 16, 2000 | Diedrich et al. |
6088694 | July 11, 2000 | Burns et al. |
6301601 | October 9, 2001 | Helland et al. |
6449627 | September 10, 2002 | Baer et al. |
6526416 | February 25, 2003 | Long |
6970883 | November 29, 2005 | Ku et al. |
- Papadopoulos, C.V.; discloses heterogeneity of distributed databases integrating commit protocols; Distributed Computing Systems, 1994., Proceedings of the 14th International Conference; Jun. 21-24, 1994; pp. 380-386.
- Inseon Lee; Yeom, H.Y. discloses a single phase distributed commit protocol for main memory database systems Parallel and Distributed Processing Symposium., Proceedings International, IPDPS 2002, Abstracts and CD-ROM, 2002; pp. 14-21.
Type: Grant
Filed: Feb 26, 2004
Date of Patent: Jul 26, 2011
Assignee: Hewlett-Packard Development Company, L.P. (Houston, TX)
Inventors: Darrell F. High (Arlington, TX), Robert S. Shaw (Cupertino, CA)
Primary Examiner: Sana Al-Hashemi
Application Number: 10/788,046
International Classification: G06F 17/00 (20060101);