Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-09-17
2003-09-30
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06629153
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer-related systems, and more particularly to shared objects in an object-oriented environment.
2. Background Art
In the development of software applications, it is becoming more common for separate applications to interact with each other such that data processed in one application is accessed from another application as well, and possibly further processed. The utility of each application is increased by its inclusion in a suite of related applications that each provide some function with respect to the common data. Mechanisms exist for sharing data by encapsulating the data in objects which are shared among the applications. One application creates the object, and then other applications are able to obtain a reference to the object and share its data via the methods or interfaces provided by the shared object.
However, each shared object is owned by the host application that created it. This means that the shared object resides within the host application, and that, when the host application shuts down, all of its associated shared objects are terminated, depriving all other applications of access to the shared data. Also, all applications access the shared object indirectly via the host application. This indirect access of the shared object is many times slower, and much more expensive in processor resources, than direct access to the object. There is therefore a shutdown problem and a performance problem inherent in this mechanism for sharing objects between applications. To better illustrate the problems associated with sharing objects, description is given below with respect to application process spaces and one software technology which facilitates the sharing of objects, the object linking and embedding (OLE) technology from. Microsoft Corporation, built upon the component object model (COM).
Application Process Spaces and OLE/COM
Each application or process has its own assigned “process space” comprised of logical addresses. Each process is assigned random access memory (RAM) comprising those locations in random access memory that are accessible to the given process (i.e., address space). Logical addresses in each process space are mapped to actual physical addresses of random-access memory independently of any other process space. For example, logical (or process) addresses
0
-
1800
for process space A. may be mapped to physical addresses
700
-
2500
, whereas logical addresses
0
-
1800
of process space B may be mapped to physical addresses
2501
-
2801
and
3000
-
4500
. A logical address of 300 within process space A maps to a completely different and independent location in RAM than the same logical address within process space B.
Operations or function calls which occur within a single process are commonly referred to as “in-process” calls, whereas function calls which involve crossing the process boundary to be completed in a separate process space are commonly referred to as “cross-process” calls. The OLE/COM system typically manages cross-process calls by marshalling the calls using an LRPC (lightweight remote procedure call) packet mechanism.
When a client process issues a cross-process function call directed to a server process across a process boundary, the remoting code of the OLE/COM system (e.g., an object proxy) marshals the function call on the client side, including generation of a marshal packet. The system processor then performs a context switch to transfer operation from the client process to the server process. On the server side, further code for remoting the function call(e.g., stub code) unmarshals the marshal packet and initiates the function callin the server process. Any returned response from the server process is similarly marshalled back to the client process with the associated context switch from server process to client process.
In contrast, in-process function calls are processed directly, without the need for marshalling or context switching. As a result, cross-process function calls may be up to 1000 times slower than in-process function calls. Unfortunately, the sharing of objects in the OLE/COM system is strongly dependent on cross-process function calls.
FIG. 1A
illustrates the system structure of an OLE/COM system. System hardware
106
, such as a personal computer, is used to execute and support an operating system
105
, such as the windows NT or other available operating systems. The OLE
103
and COM
104
software subsystems execute on top of the operating system and form a platform for the creation, management and interaction of OLE/COM objects. Processes
100
-
102
operate on top of this OLE/COM platform.
The OLE/COM system includes an API (application programming interface) supporting calls for services such as standard marshalling, and proxy/stub pair remoting code defined using IDL (interface definition language) is maintained to service standard marshalling calls. The OLE/COM system includes an object server registry for locating an appropriate object server for a given object class ID. Information regarding what methods an interface supports, and the types of parameters required by each method, may be obtained from a type library.
OLE/COM objects comprise one or more interfaces by which object methods may be invoked. Each interface represents a contract between the client accessing the interface and the object serving the interface. Every OLE/COM object includes the IUnknown interface, which, when queried, provides information about the other interfaces supported by the respective object. The interfaces of an OLE/COM object are identified by pointers in a pointer table. These pointers have meaning only within the process space in which the object is created, or instantiated.
Object data is encapsulated within the object and is accessed via the supported interfaces. One piece of data that exists within each OLE/COM object is a reference count. The reference count is incremented for every new reference to the object, and decremented when a reference is no longer in use. The object can be terminated and its resources released when the reference count is at zero, or when the host process itself terminates. Objects may be created by class factories of an object server resident within a process space or an object server resident within a dynamic linked library (DLL) appended to a process space.
Cross-Process Object Sharing
Sharing dynamically created objects across multiple process spaces is a difficult problem to solve in a generic sense. OLE/COM supports the following object sharing mechanisms shown in
FIGS. 2A-2C
.
FIG. 2A
illustrates two processes, process A and process B, residing in respective process spaces
200
and
201
. Between process spaces
200
and
201
is a conceptual process boundary representing a separation between independent process spaces
200
and
201
. Object
202
is instantiated within process A, with all associated pointers to interfaces defined with respect to process space
200
. Process A is considered to “own” object
202
, because object
202
exists only within the process in which it is instantiated. All calls on the interfaces of object
202
from process A are made as direct, in-process function calls.
However, if another process, process B, somehow acquires a reference to object
202
, the OLE/COM system instantiates a proxy object
203
within process space
201
which presents all defined interfaces of object
202
to process B. Stub code
210
is activated within process A, and proxy object
203
is linked to the stub code. When process B initiates an in-process function call on proxy object
203
, the function call is marshalled through the process boundary by remoting code in proxy object
203
using the standard OLE/COM cross-process marshaller. Stub code
210
unmarshals the function call within process A, and executes the function call in-process on object
202
in process space
200
. Return values in process A from object
202
are marshalled back through the process
Gupta Neeraj
Price Andrew
Follansbee John
Opie George L.
Trilogy Development Group, Inc.
LandOfFree
Method and apparatus for providing peer ownership of shared... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for providing peer ownership of shared..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for providing peer ownership of shared... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3001514