Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-11-07
2003-04-08
Lao, Sue (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06546412
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of Invention
This invention relates generally to object transition control and locking. More particularly, this invention is directed to the use of temporary states for objects, nested locking of objects along a single thread or control flow, and attribute-based locking of an object.
2. Description of Related Art
State-model algorithms are used where each program object, or object, manages itself A process from anywhere in the system may send an event to an object, requesting that the object perform a certain action upon itself Depending upon the action requested in relation to the current state of the object, the object transitions itself to a predetermined state in which it performs a series of commands. Many externally-generated requests transmitted to objects may cause the objects to initiate subsequent actions upon themselves and/or upon other secondary objects. State-model algorithms generally stipulate that the commands performed by a given state must be predetermined and must not rely upon knowledge of the previous state of the object or of the action requested which led the object to its current state.
Objects in a system may be subject to read or write locks, which restrict access to the object in order to preserve the integrity of the data or attributes associated with that object. Locking, or more generally the process of barring use of a file, database object, or any other embodiment of object information, is used in situations when more than one object or user might try to access the same file, database record, or other object data at the same time. In a multi-threaded environment, many users can read from or write to commonly accessed information storage areas. If a read lock is applied to a given storage area, other objects may continue to read from that storage area. However, if a write lock is applied to the storage area, then no other entity is allowed to read form or write to the locked storage area, Thereby preventing another process from interfering with the object's data while the data is being updated.
When a standard, state-based, object-oriented model is created, temporary object states, nested locking, and attribute-based locking may not be available.
SUMMARY OF THE INVENTION
This invention provides new mechanisms for locking any shared entity within the same thread or process flow, thereby creating a system that allows a hierarchy of locking of shared entities along a single thread or flow of control.
This invention also provides new forms of temporary states that combine event-based modeling with state-based modeling.
This invention further provides for attribute-based locking which, in the context of an object state model, allows for selective locking of objects while they are in predetermined states.
In an event-based model, actions to be performed upon an object are determined by the event requested of the object. In a state-based model, the actions to be performed are determined by the state to which the object is sent due to a requested event. In a state-based model, there may be more that one event which could lead the object from the same starting state to the same destination state. Also, a single event may send the object from one of any number of starting states to a single destination state.
Where there exists a single starting state and a single destination state, there may be certain interim work which needs to be performed, depending upon the action requested. This work cannot be associated with the final destination state because it is not relevant for all occasions when the object might be in that state. This invention, which is based upon the state-based model, provides temporary states to perform this interim work before sending the object to its final destination state. This temporary state is used only during runtime and is unknown to the object database. Furthermore, this temporary state itself initiates an action on the object to send the object to the correct final state upon completion of the required interim work.
When an object may be coming from any number of different states to a single destination state, there exists a situation where, depending upon from which state the object is coming, unique interim work may need to be performed. In this situation also, it is useful to use temporary states to perform the interim work before sending the object to its final state.
By using temporary states in the above situations, violation is avoided of the traditional state-based model guidelines which provide that a given state need not know the previous state of an object or the action requested of it. All temporary and permanent states have pre-defined actions which do not rely upon any knowledge of the previous state of the object. The reaching and leaving of these states is entirely determined by the pre-defined object-state model.
In some state transition models, it may be desirable to lock an object as it arrives in each state, perform the work required for that state, then unlock the object. Using this implementation, there might be a problem with making recursive calls when transitioning between temporary and permanent states. The concept of nested locking provides for the recursive locking of objects. Therefore nested locking may be quite useful when using temporary states which recursively generate events to transition an object through multiple states within a single request.
In a multi-threaded system, when a thread or process intends to perform some action upon a given object, it generally acquires a lock on the object, then begins its operation. In the course of this operation, it may occur that a function is called which would also like to perform some work upon this object. In this situation, in a traditional system, the called function might require some knowledge as to whether or not there has already been a lock acquired for this object. If a lock has already been acquired for it, it should avoid trying to lock the object. Conversely, the called function MUST lock the object at this point if a lock has not already been acquired.
Using the invention of nested locking, a called, or nested, function will never require this knowledge. In all cases, if a nested function needs to perform work upon an object, it will request a lock for that object. If it so happens that the caller of the function has at some point already acquired the lock, the function's request for the lock will still return normally, implying that a lock has indeed been acquired. In actuality, the lock was already in place; however, the nested function only really needs to know that a lock for this object is presently in place. The lock requested by the nested function is called a nested lock. When the nested function completes its operation, it issues a release of the lock, or unlock request, for the given object. However, because the nested function did not obtain the original lock on the object, the unlock request will not actually release the lock on the object. The request for the release of the lock WILL return normally, indicating that the unlock request succeeded, but the original acquirer of the lock will still retain a lock on the object.
Thus, within a single thread or flow of control, an unlimited number of nested locks may be acquired. A request to unlock an object will only truly unlock the object if the caller is at the highest level of locking. With this invention, for recursive or embedded functions, no knowledge with regard to the previous locking condition is necessary. This concept may be useful for object state models, where state transitions are often recursively called. This may be especially useful when temporary states are used which generate new events to transition the object to a new state.
In a multi-threaded system, a condition may occur in which locks have been obtained for two or more objects in the system, and in which subsequent operation requires the obtaining of a lock for one of the objects that is already locked. The currently locked objects will not be unlocked unt
Kim Sang W.
Nesbitt David P.
Okamoto Steve A.
Thomas Jennifer D.
Lao Sue
Oliff & Berridg,e PLC
Xerox Corporation
LandOfFree
State-based object transition control and nested locking does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with State-based object transition control and nested locking, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and State-based object transition control and nested locking will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3075678