USRE42578EExpiredUtility

Synchronization using commitment

43
Assignee: HEWLETT PACKARD DEVELOPMENT COPriority: Dec 15, 2000Filed: Feb 26, 2004Granted: Jul 26, 2011
Est. expiryDec 15, 2020(expired)· nominal 20-yr term from priority
G06F 16/10Y10S707/99938Y10S707/99939
43
PatentIndex Score
1
Cited by
8
References
23
Claims

Abstract

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.

Claims

exact text as granted — not AI-modified
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.

Cited by (0)

No later patents cite this yet.

References (0)

No backward citations on record.