Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-03-31
2004-01-20
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C707S793000
Reexamination Certificate
active
06681263
ABSTRACT:
BACKGROUND
This invention relates generally to object oriented software programs for computer systems and particularly to the control of the lifetimes of software objects.
There are number of object oriented software technologies including COM, C++ and Java, for example. A COM object, for example, is a piece of software with data and one or more interfaces, each with one or more methods. A method is a function or procedure accomplished by an object. An interface allows a client to access a method contained in an object by acquiring pointers to the object's methods.
Microsoft's COM programming technology makes use of reusable component software which is programming language independent. Thus, COM objects can be developed in any object oriented programming language. To use a COM object, client software must start an object by causing an instance of that object to execute. Thus, a client may start a large number of software objects which may be used for a period of time. Since objects include methods and data, they unnecessarily use up memory. Therefore it is desirable to delete these objects when they are no longer useful. The act of deleting the objects, sometimes called freeing the object, simply eliminates the instance of the object.
In COM technology, reference counting is used to determine when an object will stop executing. This in effect determines what is called the object's lifetime, which extends from the point when it is instantiated to the point when it is deleted. Reference counting is implemented by an interface called IUnknown and its methods AddRef and Release.
A client may start an object, acquire interface pointers to the object's interfaces, and then pass those interface pointers on to other clients which may in turn pass them on to still other clients. If the first client were to delete the object when the first client was done with the object, the other clients may not be able to complete their use of the object. One client generally does not know when the other clients are done with an object. Thus, the object keeps track of when each client is finished with it using reference counting. Reference counting in COM involves maintaining a 32 bit reference count, stored in system memory.
Whenever an interface pointer is passed to a new client, the object adds one to its reference count. A client that receives an interface pointer from a client must invoke the add reference method (“call AddRef on the pointer”) using the pointer. The referenced object then increments its reference count. Generally, in COM technology, it is the client that invokes AddRef and Release. When the client is done with the interface pointer, it is must call Release on that pointer. This causes the object to decrement its counter.
Thus, in COM technology, an object self-destructs, deletes itself or frees itself when its reference count is zero. In this way, the reference count determines the object's lifetime.
In COM technology, artificial reference counting allows the reference count to be artificially incremented to prevent inadvertent deletion of the object. See COM Specification, Microsoft Corporation (1995), Chapter 3, Section 1.3, available at www.microsoft.com (hereinafter the Microsoft COM Specification). The Microsoft COM Specification indicates that an implementation of a method may invoke functions which have a chance of decrementing the reference count, causing the object to release before the function returns to the object. This would cause a crash. One way around this is to insert an AddRef at the beginning of the method which is paired with a Release just before returning:
void IInterface: :FOO(Void) {
this →AddRef ( ) ;
/*
*Body of Foo, as before except short-circuit returns
* need to be changed.
*/
this→Release ( ) ;
return;
}
This use of artificial reference counts guarantees object stability while processing is done, according to the Microsoft COM Specification.
However, the artificial reference counting techniques described in the Microsoft COM Specification do not give considerable flexibility. The object's lifetime is effectively determined synchronously because once the program reaches the inserted Release, the reference count is decremented and the object will be deleted, regardless of whether the object was able to complete all necessary tasks. This could be a substantial problem in a number of instances which involve asynchronous tasks. An example of an asynchronous task would be terminating a remote network connection, which may take an indeterminant amount of time. The object may need to wait for a response from the remote network (which response time may be determined by various network conditions).
Another system for determining object lifetimes is provided by the Java software which does not use reference counting but instead uses what is somewhat inelegantly called a “garbage collector”. From time to time, the garbage collector examines objects to determine whether there are any remaining references from clients to that object. When all of those references have been released, the garbage collector deletes the object. Thus, it may be that the garbage collector realizes that the object is no longer referenced and deletes the object at an inopportune time. The object may, for example, be attempting to complete a task when it is deleted. The client may well expect incorrectly, that the object, while no longer referenced, will complete certain necessary tasks after its reference has been released.
Thus, there is a continuing need for software technologies which enable flexible control of object lifetimes.
SUMMARY
In accordance with one aspect, a method of controlling the lifetime of an object shared by multiple clients in a computer system involves deleting the object if the object is in a first state when all client references to the object are released. The object is preserved if it is in a second state when all client references to the object are released.
In accordance with another aspect, a method for controlling an object's lifetime in a computer system may include notifying the object when all clients have released the object. Thereafter, the object is deleted.
REFERENCES:
patent: 4912629 (1990-03-01), Shuler, Jr.
patent: 5136712 (1992-08-01), Perazzoli, Jr. et al.
patent: 5931919 (1999-08-01), Thomas et al.
(Kwan) Kwan, Doug. “Practical distributed garbage collection for networks with asynchronous clocks and message delay.” pp. 406-411, Jun. 1994.*
Internet. “Reference counts”, “Counting xPops”. www.cs.arizona.edu/xkernel/manual/subsection3_12_2.html, Feb. 21, 1996.*
(Chappell) Chappell, David. “Understanding ActiveX and OLE”, p. 51-52, Sep. 1996.*
(Vanderburg) Vanderburg, Glenn. “Tricks of the Java Programming Gurus”, Jul. 1996.*
Microsoft Corporation, The COM Specification. Chapter 3. Objects and Interfaces, (1995), pp. 1-23.
Bullock, Jr. Lewis A.
Follansbee John
Intel Corporation
Trop Pruner & Hu P.C.
LandOfFree
Control of software object lifetime does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Control of software object lifetime, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Control of software object lifetime will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3210354