WO2000045239A2 - Method and system for multi-threaded object loading and unloading - Google Patents
Method and system for multi-threaded object loading and unloading Download PDFInfo
- Publication number
- WO2000045239A2 WO2000045239A2 PCT/US2000/002015 US0002015W WO0045239A2 WO 2000045239 A2 WO2000045239 A2 WO 2000045239A2 US 0002015 W US0002015 W US 0002015W WO 0045239 A2 WO0045239 A2 WO 0045239A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- poa
- count
- thread
- servant
- request
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Definitions
- the present invention relates to distributed object systems and more specifically loading and unloading of objects using multi-thread.
- transaction-based applications function in the following way.
- a software application program which executes on a client, initiates a transaction that requires access to services provided by a distant computer, called a server. Examples of these services could be an update to a database such as a bank's database, an execution of a purchase order such as in the case of purchase of a security and the like.
- the client sends a "request” message to the server, which then sends a "response” message containing a response to the request.
- the server is not a single computer, rather a collection of interconnected heterogenous computers.
- the request message must then be formatted in such a way that all the interconnected computers can understand and respond to the request message.
- the collection of interconnected computers is configured in an object-oriented programming model, then software object (or objects) that are capable of working together to provide a response to the request message can be distributed among the several computers.
- the objects in order to access the objects from a remote computer the objects must somehow publish their existence, their addresses, their properties, the services they provide, and other details to the "outside" world. Then, a client may be able to use the services provided by sending a request message in a manner similar to making a remote procedure call ("rpc") and obtaining a response to that message.
- rpc remote procedure call
- DCOM Distributed Component Object Model
- Java/RMI Java/Remote Method Invocation
- CORBA Object Management Group's Common Object Request Broker Architecture
- Objects that provide services are typically located on servers. These objects are queried by applications running on clients using a specified data communication transport layer protocol — the Object Remote Procedure Call (ORPC) for DCOM; the Java Remote Method Protocol (JRMP) for Java/RMI; and the Internet Inter- ORB Protocol (HOP) for CORBA.
- ORPC Object Remote Procedure Call
- JRMP Java Remote Method Protocol
- HOP Internet Inter- ORB Protocol
- a client suitably formats a query message in the appropriate protocol language and transmits the query message, which is routed to the appropriate server, whereupon it is executed, and a response message is formatted and routed back to the client.
- object may mean the object definition, associated operations, attributes, etc., and implementation for that object.
- object type is used to refer to the definition of the operations and attributes that software external to the object may use to examine and operate upon the object.
- object type is also known as the "interface.”
- object may be used to refer to an actual run-time instance of an object and will be made clear by the context.
- a server configured to be a Java/RMI server comprises objects that have predefined interfaces, which can be used to access the server objects remotely from another machine's Java Virtual Machine (JVM).
- JVM Java Virtual Machine
- a Java/RMI server object interfaces declare a set of methods that indicate the services offered by that server object.
- a program resident on the server called an RMI Registry stores and makes available to clients information about server objects.
- a client object obtains information regarding the methods and other properties of a server object by performing an operation such as "lookup" for a server object reference. This lookup typically works by the client object specifying an address in the form of a Universal Resource Locator (URL) and transmitting the address to the server's RMI Registry.
- URL Universal Resource Locator
- the clients and servers also include interceptors.
- the interceptors provide hooks to programmers to execute their piece of code at certain points during ORB. Typical uses of the interceptors include: transaction service integration, security message compression and encryption, fault tolerance and other operations such as tracing, profiling, debugging, logging.
- ORB Object Request Broker
- Each CORBA server object exposes a set of methods, and it declares its interface.
- a CORBA client obtains an object reference and determines which methods are provided by the object.
- a CORBA client needs only two pieces of information: a remote object's name, and how to use its interface.
- the ORB is responsible to locate the object, provide a vehicle by means of which a query is transmitted to a server object and a response is transmitted back to the client object.
- a CORBA object interacts with an ORB by either using an ORB's interface or using an Object Adapter.
- BOA Basic Object Adapter
- POA Portable Object Adapter
- the BOA typically has methods for activating and deactivating objects, and for activating and deactivating the entire server. These are intended for systems where the ORB and the server are separate programs or even on separate machines. Different vendors supplying CORBA-compliant servers ordinarily choose one or the other of these methods of an object-ORB interaction.
- CORBA objects take form within server applications.
- CORBA objects are implemented and represented by programming language functions and data.
- the programming language entities that implement and represent CORBA objects are called servants.
- a servant is an entity that provides a body for a CORBA object, and for this reason, the servant is said to incarnate the CORBA object.
- Object adapters such as the CORBA-standard Portable Object Adapter (POA) mediate between an ORB and a set of programming language servants.
- POA Portable Object Adapter
- Each POA instance represents a grouping of objects that have similar characteristics.
- POA policies are a set of objects that are used to define the characteristics of a POA and the objects created within it.
- the CORBA standard specifies that interfaces for POA, POA manager (which is a class to manage multiple POAs) and the POA policies should be defined in a standard module. Further, the POA policies can also define how threads are to be operated. A thread-of-execution (a thread) is a sequence of control within a programmed-process.
- a multi-threaded process has several sequences of control, and is capable of several independent actions.
- Conventional multi-threaded software packages provide functions to create a thread and to begin execution.
- the software packages also provide a number of synchronization methods, such as MUTtual Exclusion (mutexes), condition variables and semaphores, etc.
- a synchronization operation is implicated when two or more threads have to share a resource. Without proper synchronization, the threads may conflict with each other. For instance, one thread can operate on a value while another thread can attempt to change that value.
- Traditional solutions to this problem have resorted to the use of mutual exclusion primitives.
- a thread Before claiming a resource a thread must typically first obtain a lock on the resource. By definition, when obtaining the lock the thread knows that no other thread owns the lock for the resource, and that the thread is thus free to use the resource. If a second thread desires to claim the resource, it must wait to obtain the lock until the first thread is finished using the resource. When the first thread finishes using the resource, it releases the lock for the resource, thereby allowing other threads to access the resource.
- an Active Object Table registers objects that are active. Conventionally, in order to achieve the synchronization, the AOT is mutexed for duration of load. This prevents spawned threads from accessing the AOT.
- recursive mutexes are utilized in some conventional systems. However, the recursive mutex still has table level granularity. Another approach is to use multiple mutexes by providing one for a table and one for each object. This may achieve object level granularity, but it causes a large number of mutexes possibly wasting resources.
- the present invention provides a thread that can load or unload objects outside of a mutex lock and can access the Active Object Table (AOT) during loading and unloading.
- the present invention further provides loading or unloading thread that can spawn other threads, which in turn can access the AOT.
- the present invention further provides object level granularity for serialization. For instance, four (4) threads trying to load object A would be serialized but any thread would be able to access object B while A was being loaded.
- the present invention provides a method of controlling a life cycle of an object in a multi -thread computing environment.
- the method includes the steps of creating a table containing a list of active objects and determining whether or not an object is listed in the table. If the object is not listed in the table, then the method provides the steps of mutex locking the table, entering an object id of the object into the table, setting a first count associated with the object id in the table to value of one, and unlocking the mutex lock without waiting until the object is completely loaded. If the object is listed in the table, then the method can provide the steps of incrementing the first count, and determining whether or not the object is etherealizing.
- the method can also provide the steps of waiting the object to be completely etherealized, and reactivating the object.
- the method can further comprise the steps of incrementing the first count when an additional request is made to the object, and decrementing the first count when the request is dispatched on the object.
- the method may also include the step of deactivating the object only when the first count is equal to zero.
- the present invention also provides a method for controlling a table containing a list of active objects.
- the table is accessed by one or more threads in a multi-threaded computing environment.
- the method includes the steps of mutex locking the table with a first thread when activating an object provided that the table is not locked by a second thread, and creating an entry for the object in the table when the entry does not exist in the table, wherein the entry includes a reference count.
- the method also comprises the steps of incrementing the reference count of the object if the table is locked by the second thread, and unlocking the table from the mutex lock after incrementing the reference count whether or not the object is completely activated.
- the method may also provide the steps of etherealizing the object only when the reference count of the object is zero, and incrementing a reactivation count if the object is etherealizing when the first thread attempts to activate the object, wherein the entry of the table further includes the reactivation count. Further, the method can also comprise the steps of broadcasting the reactivation count to wake any waiting object to reactivate the etherealized object, and decrementing the reference count after dispatching a request on the object. It should be noted that the method can also include the step of deactivating the object only when the reference count is equal to zero.
- the present invention also provides a server computer in a client-server computing environment.
- the sever includes a memory configured to store a table containing a list of active objects and a processor configured to determine whether or not the object is listed in the table.
- the processor if the object is not listed in the table, is further configured to mutex lock the table, to enter an object id of the object to be activated into the table, to set a first count to one, and to unlock the mutex lock without waiting until the object is completely loaded.
- the first count is associated with the object id in the table.
- the processor can be further configured to increment the first count and to determine whether or not the object is etherealizing if the object is listed in the table.
- the processor can also be configured to wait the object to be completely etherealized, and to reactivate the object if the object is etherealizing.
- the processor can also be configure to increment the first count when an additional request is made to the object and to decrement the first count when the request is dispatched on the object.
- the processor can be configured to deactivate the object only when the first count is equal to zero.
- FIG. 1 is a diagram illustrating a computer network for the distribute objects of the present invention
- FIG. 2 is a block diagram of a typical computer of the present invention
- FIG. 3 is a state machine diagram illustrating the life cycle of the Portable Object Adaptor the present invention
- FIG. 4 a structural diagram illurstrating an Active Object Map of the present invention
- FIG. 5 is a state machine diagram illustrating an object in the present invention.
- the network 10 includes a computer 12 coupled to a network 14.
- the network 14 can further include a server, router or the like 16 in addition to other computers 18, 20, and 22 such that data, instructions and/or messages can be passed among the networked computers.
- a mass storage devices 24 may also be connected to the server 16 or to any of the computers.
- some computers 12, 18 may include an independent network connection between them, whereas other computers 20, 22 may not include such a connection.
- Various ways to design, construct and implement the computer network as known in the art are contemplated within this invention.
- each computers 12, 16, 18, 20, and 22 includes a processing unit 42, a primary storage device 44 and a secondary storage device 46.
- the processing unit 42 can be, but not limited to, a central processing unit (CPU), or multiple processors including parallel processors or distributed processors.
- the primary memory device 44 includes random access memory (RAM) and read only memory (ROM).
- the RAM stores programming instructions and data, including distributed objects and their associated data and instructions, for processes currently operating on the processor 42.
- the ROM stores basic operating instructions, data and objects used by the computer to perform its functions.
- the secondary storage device 46 such as a hard disk, CD ROM, magneto-optical (optical) drive, tape drive or the like, is coupled bidirectionally with processor 42.
- the secondary storage device 46 generally includes additional programming instructions, data and objects that typically are not in active use by the processor, although the address space may be accessed by the processor, e.g., for virtual memory or the like.
- each of the above described computers can include an input/output source 50 that typically includes input media such as a keyboard, pointer devices (e.g., a mouse or stylus) and the like.
- Each computer can also include a network connection 52.
- Other variations of the above discussed the computer and its components available to one of skill in the art are also contemplated within the present invention.
- computer network is defined to include a set of communications channels interconnecting a set of computer systems that can communicate with each other.
- the communications channels can include transmission media such as, but not limited to, twisted pair wires, coaxial cable, optical fibers, satellite links, and/or digital microwave radio.
- the computer systems can be distributed over large, or "wide" areas (e.g., over tens, hundreds, or thousands of miles. WAN), or local area networks (e.g., over several feet to hundreds of feet, LAN).
- various local- and wide-area networks can be combined to form aggregate networks of computer systems.
- One example of such a network of computers is the "Internet".
- MT multi-thread
- a requirement for a multi-thread (MT) component is the ability to synchronize access to internal data structures. While a simple requirement, designing for synchronization is complex, and requires great care to avoid deadlock and simplify development and maintenance while enabling concurrency and performance. Of particular concern is the granularity at which mutual-exclusive (mutexes) locks are applied. An excessive number of mutexes increases resource usage and significantly complicates code, while too few of mutexes reduces concurrency and performance.
- mutexes mutual-exclusive
- Portable Object Adaptor uses a single mutex to protect access to all data within the POA hierarchy for a particular ORB. Effectively, each RootPOA owns a mutex which is shared by all of its children. This approach was chosen for several reasons. First, several data structures (such as the Active Object Map and Child POA Map) may be shared across multiple POAs to reduce the cost of an individual POA - critical for supporting servers that require a large number of POAs (a likely situation, given that server-side QoS is specified at the POA level). Access to these shared data structures will need to be protected by mutex which is similarly shared across POAs.
- data structures such as the Active Object Map and Child POA Map
- POA creation and destruction An example of this can be seen in POA creation and destruction.
- POA creation requires read access to the parent POA state and parent POA list, and changes the state of child POAs.
- POA destruction is similar - destruction of a POA modifies its own state, its children's state, and its parent's child POA list within the same critical section. This makes it very complex to protect each POA its own mutex -access to each POA must be very carefully coordinated to prevent deadlock. The additional complexity raises maintenance cost, increases the likelihood of hard-to-diagnose errors, and makes the code base more fragile.
- calls to methods are preferably not made from system code to application code with an internal mutex locked - doing so introduces mutex layering, and opens the possibility for deadlock.
- the POA unlocks its internal mutex prior to calling any of the following methods:
- FIGs. 3 and 5 illustrate state machine diagrams.
- the state machine diagrams are simple and natural mechanism for modeling the lifecycle of objects within a multithreaded environment of the present invention. More specifically, a state machine includes three elements - an enumerated state variable, a reference counted condition variable, and a reference to an application-specific mutex. The mutex is controlled directly by the application; this allows the application to access the state and other resources within the same critical section.
- Three operations are available on a state machine: querying the current state, changing the state, and waiting to enter a state.
- the thread locks the application mutex and checks the enumerated state variable.
- the thread locks the application mutex, updates the enumerated state variable, and issues a broadcast on the condition variable (if it exists).
- the thread waits on the condition variable (simultaneously releasing the application mutex) and is woken when the state changes. When woken, the thread rechecks the state - if the state is still not desirable, the thread waits on the condition variable again.
- Condition variables are potentially costly resources; therefore, they are preferably maintained only when necessary.
- the POA of the present invention uses a reference counting approach to ensure that condition variables are created and destroyed on demand. The first thread to wait for a state allocates the condition variable and its reference count, and sets the count to 1 ; subsequent threads simply increment the reference count.
- FIG. 3 illustrates the POA life cycle of the present invention in a state machine diagram.
- the POA states include:
- Running, 104 The POA is accepting and dispatching requests.
- the POA events include:
- creat e_POA is called directly by the application.
- the explicit POA creation occurs when an application directly calls creat e_POA.
- This form of creation is an atomic operation; the parent creates a new child POA instance, registers its interceptors with the binding manager, and places it in the Running state 104.
- the parent creates a new child POA instance, registers its interceptors with the binding manager, and places it in the Running state 104.
- the POA will exist and accepting requests.
- Explicit POA creation is only allowed when the POA with the given name does not exist, or when the POA with the given name is Etherealizing (i.e., unloading an object). In the latter case, create_POA must wait until the previous POA is completely destroyed before attempting to create a new POA instance.
- create_POA is called by an AdapterActivator
- Implicit POA creation occurs when an application calls f ind_POA with the activate_it flag set for a POA that does not exist or a POA that is Etherealizing.
- f ind_POA invokes unknown_adapter on the AdapterActivator associated with the parent.
- the AdapterActivator will eventually result in a create_POA call, creating the POA instance.
- the behavior of a POA is slightly different when created by an Adapt erAct ivator. In such a condition, the POA acts as if its POAManager were in the holding state in the time between creation and the return from unknown_adapter.
- f ind_POA pushes a flag onto the thread specific stack prior to calling the AdapterActivator, and create_POA checks for this flag to determine if the invocation was made as part of an AdapterActivator call or as of a direct application call. If the flag exists, creat e_POA creates a new POA instance but places it in the Created state 102, and defers registering its interceptors. This allows find to return the newly created POA and prevents create from creating a POA with the same name, but causes requests intended for objects in the newly created POA (or any of its children) to arrive at the parent's child activation interceptor.
- this interceptor will see the POA has been Created and will queue the requests for later delivery.
- unknown_adapter returns, the parent activates the new POA, changing its state to Running 104, registering its interceptors with the binding manager, and redispatching any queued requests through the binding manager before returning the POA instance.
- unknown_adapter is called outside of a mutex, it is not an atomic process. This makes it possible for an application to call POA : : destroy after the POA has been created but before the AdapterActivator has returned. This is handled by placing the POA in an intermediary Stillborn state 103, then blocking on the condition variable. When AdapterActivator : : unknown_adapter returns, the creating thread will see the state as Sillborn 103 and transition it to Destroying 105, unblocking the destroying thread.
- Implicit Create Complete The AdapterActivator call which created the POA has returned.
- a POA can be located using the find call only if it exists in its parent's child POA list, and its state is not Etherealizing.
- a POA enters the Destroying state 105 when POA : : destroy is first called and the POA either has children or is processing requests. The POA can only exit this state when all outstanding requests have completed, and all children have been completely destroyed. This is complicated by the possibility that in- progress requests will re-create some of the POA's children.
- the destroying thread creates a gateway on the stack and spins in a loop. On each pass through the loop the thread checks the child POA list; if it is not empty, the thread walks the child list and destroys each child, waiting for completion. When the POA's list of children is empty, the destroying thread checks if there are methods in progress. There are two parts to this condition.
- the thread checks a request in progress count maintained by the POA. This count is incremented when a request arrives at the POA's request interceptor and decremented after the POA performs cleanup from a request. If this value is zero, the destroying thread knows that there are no requests executing within the POA. However, this is insufficient - there may be requests that are in the POA's interceptor chain, but have not yet reached the POA itself. To handle this, the binding manager allows the POA to remove an interceptor only if it is inactive. If the interceptor cannot be removed, then there are still requests outstanding and the POA cannot be destroyed. In this case, the destroying thread releases the POA mutex and waits for the request in progress count to reach zero.
- the destroying thread wakes and loops, destroying any recreated children, rechecking the request in progress count, and removing the server binding.
- the request progress count has reached zero and the server binding can be removed, the POA begins servant etherealization. This may cause strange results for method implementations that create child POAs. The method would be able to create the child, but might see an OB JECT_NOT_EXI ST exception when attempting to use that child.
- the POA enters the Etherealizing state 106 after quiescence if the application request servant etherealization. In this state, POA operations throw OBJECT_NOT_EXIST, find calls throw AdapterNonExistent, and incoming requests for the POA are discarded, but create calls wait until the POA has been completely destroyed.
- the POA will transition from Etherealizing 106 to Destroyed 107 when all servants have been etherealize.
- OBJECT_NOT_EXIST and create calls will proceed as normal.
- the actual POA instance will continue to exist until its reference count reaches 0, but operations called on that instance will throw OBJECT_NOT_EXIST.
- applications can choose between waiting for POA destruction to complete, or returning before the POA is actually destroyed.
- the thread calling POA : destroy walks the POA through destruction directly; it waits for quiescence and etherealizes the POA's servants before returning.
- PO destroy simply changes the POA's state to marks it as requiring destruction, then posts an item to the ORB work queue. The thread handling this work item will actually walk the POA through destruction.
- processing is performed by the Servant Request Interceptor, a per-POA interceptor registered with a binding name of [endpoint_f ormat_id : endpoint_id] .
- Objects created by the POA use an object- key of [endpoint_f ormat_id : endpoint_id : oid] .
- the binding manager performs a best-match lookup on the object key, finding and dispatching the request to the interceptor associated with the POA.
- the Servant Request Interceptor performs the following basic functionality:
- the Binding interface establishes a chain of request and message-level interceptors to represent a binding, or channel of communication between client and server.
- the Binding : : ThreadContext instance carries local ORB-service-specific information associated with the request. Its accessor can be called at any time and the result must not be released.
- Typical ORB service implementations will use information from the in_service_contexts attribute to initialize their local state in the thread_context before calling invoke ( ) on the next ServerRequest Intercept or, and then make this state available to applications via an object with an interface derived from CORBA : : Current.
- the POA may create the servant using its associated ServantManager, if necessary. For example, a POA using a Servant Act ivator might incarnate the servant at this time.
- the POA also increments its "requests in progress" count to prevent itself from being destroyed while this request is executing. Exceptions thrown at this point are reported to the client and abort the request processing.
- the actual request processing strategy (USE_DEFAULT_ SERVANT vs. USE_SERVANT_MANAGER vs. USE_AOM_ONLY) is preferably performed by the POA itself, rather than by the interceptor. This eliminates the need for accessing internal POA data in the interceptor, allows a single interceptor implementation to support multiple strategies, and simplifies the development of colocation by encapsulating the request processing mechanism within the POA. Most forms of request processing can perform request cleanup after the response has been sent - since exceptions generated at this point should not be reported to the client, there is no need to add the overhead of cleanup to method execution times. Unfortunately, the CORBA 2.3 specification places additional restrictions on the use of servant location - in servant location, cleanup is performed as part of the request, and any exceptions thrown from ServantLocator : : post invoke is be reported to the client.
- ServerRequestCallback write_output s is called after the request is processed but before the response is sent, this allows cleanup as part of the request and properly return exceptions to the client.
- the step of servant retention preferably uses an Active Object Map (AOM).
- AOM Active Object Map
- the Active Object Map acts as a two dictionary: relating object ids to servants and servants to object ids.
- USE_SERVANT_MANAGER policy have more complicated logic for adding and removing entries in the AOM, as described below.
- the primary requirement for the Active Object Map is scalability to large numbers of registered objects. Enabling this requires minimizing the amount of data stored per object.
- Tables 1-3 demonstrate the amount of data required per object. They do not include the overhead required by internal dictionary structures; this is expected to add between 8 and 12 bytes per object.
- a secondary requirement for the Active Object Map is the ability to scale to large numbers of POA. This could be accomplished by making the Active Object Map hashtables (a relatively costly resource) ORB-global rather than per-POA. However, this approach may require increasing the amount of data stored per-object, as the POA reference is stored as part of the key for each hash table to enable each POA to locate only its own registered objects. Further, the Active Object Maps can be kept per-POA, rather than per- ORB. In addition, child POA lists (another Rash-table) is preferably made ORB-global as well, again adding the parent POA as part of the key field.
- FIG. 4 illustrates an exemplary Active Object Map.
- An ID to Servant Map 121 is used to match the Object Id contained within a request to a servant, as well as to implement the id_to_servant and id_to_reference methods.
- Each entry in the map is an Act ive Obj ect record, containing an Obj ect Id and a servant.
- the map key is a pointer to the Obj ect Id in the ActiveObj ect record.
- Table 1 shows the memory usage required per-object in the ID to Servant Map 121:
- a Servant ID Map 123 is used to implement the servant_to_id and servant_to_ref erence methods. It is also used to determine if there are outstanding activations on a servant during etherealization.
- the map relates servant references to a ServantUsage record.
- the ServantUsage record consists of two elements: a usage count for that servant, and an Obj ect Id reference. The usage count can be queried to determine if there are other, outstanding activations for the servant - for example, this provides the proper value for the remaining activations parameter in Servant Act ivator : : etherealize.
- the Objectld is a reference to the id with which the servant is associated.
- the id is reference to the Obj ect Id stored within the Act iveOb j ect associated with the servant. If the POA uses the MULTI PLE_ID policy, the id is always null.
- Table 2 shows the memory usage required per-object in the Servant to ID Map 123:
- Servant retention with servant activation is complicated by possible interactions between servant incarnation and activation, and the need to serialize calls to incarnate and etherealize on a particular object.
- the process for incarnating and etherealizing servants using a ServantActivator is modeled as a state machine. Each servant is associated with a state variable and an on-demand condition variable. The state variable is protected by the per-ORB mutex. Servants are incarnated and etherealized, and Active Object Map entries are added and removed in response to state transitions.
- Active Object Map consists of four elements: an explicit state variable, an on-demand condition variable, an outstanding reference count, and a reactivation count. Again, the amount of state information is designed to be as minimal as possible. Table 3 shows the storage types and total memory usage required per-object, beyond that already required for servant retention:
- the reference count prevents premature etherealization of an object; an object is etherealized only when the reference count is zero. This has the effect of serializing the state machine in the Terminating state; a thread can prevent the object from passing the Terminating state by incrementing the reference count.
- the reference is incremented during method dispatching to prevent etherealization while a method is in-progress. It is also used during servant reactivation; when a servant is reactivated, the reference count is set to the previous reactivation count. This prevents the new servant from being etherealized until all threads waiting for the new servant incarnation have completed processing.
- requests may arrive or activate attempts may be made on an object while it is being etherealized.
- the reactivation count is checked after a servant has been etherealized; if the count is non-zero, there is at least one thread waiting to incarnate or activate a new servant generation. In this case, the reactivation count will be transformed into a reference count, indicating that requests are in-progress on the object, and the waiting threads will be woken.
- the first woken thread is responsible for activating a new servant generation - if the woken thread was previously waiting for to deliver a method request, the activation is performed by calling ServantActivator : : incarnate; if the woken thread was previously waiting to explicitely activate the object, it does so immediately and returns.
- FIG. 5 illustrates the complete lifetime for an object in a retaining POA with automatic activation. Note that the diagram describes object lifetime, not necessarily the lifetime of a particular servant. Specifically, throughout the lifetime of the object, several servants may be incarnated or etherealized.
- the object states preferably include:
- Terminating The object has been deactivated, but there are still requests outstanding on the current servant. The object is considered active until all requests (both in-progress and newly arriving) have completed, at which point the object will be deactivated and the servant etherealized.
- Reincarnating, 156 The current servant has been etherealized, but one or more method requests are outstanding on the object. A new servant will be incarnated during the pre-dispatch phase of the first request.
- the present invention includes the following object events: 1. Pre-dispatch: A method invocation has been delivered to the
- Servant Deactivation deactivate_obj ect has been called for the OID. Potentially also includes
- POAManager deactivate and POA: : destroy.
- Object activation refers to the process of explicitly activating the an object using POA : : act ivate_obj ect. Activation is allowed only if the object holder does not exist, or if the object is in the process of deactivating. In the first case, activate object creates the object holder and immediately makes the object Available. In the second case, activate object blocks until the object is fully deactivated, then attempts to reactivate it. This case is discussed in more detail below in connection with Object Reactivation discussion.
- request processing consists of a pre-dispatch phase, a dispatch phase, and post-dispatch phase.
- the pre-dispatch phase is responsible for ensuring that the Servant is Available and properly updating the reference count to reflect the method in progress. If the object doesn't exist, the thread first creates a holder in the Act ivat ing state, then incarnates the servant using the ServantActivator. Once the servant has been incarnated, the thread makes the object Available, increments the reference count, and dispatches the request.
- the thread increments the reference count to prevent the servant from being prematurely etherealized, then waits for the activation to complete. When the activation completes, the thread dispatches its request.
- ServantBase : :_dispatch to up-call into the method code.
- the post-dispatch phase is responsible for cleaning up after a method invocation. Normally, this cleanup just consists of dropping the reference count. However, additional work may be required if the servant has been deactivated. In this case, pos t - dispatch checks the reference count after decrementing. If the reference count has dropped to zero, we know this is the last request outstanding on the given servant. The object's state is changed to Etherealizing, and the thread up-calls
- ServantActivator : etherealize. Because etherealize occurs outside of mutex control, it is possible for requests to be delivered or for a thread to call act ivate_obj ect while an etherealize call is in progress. Either of these conditions will cause the object's reactivation count to be incremented, as described below in connection with Servant Reactivation. Assuming reactivation does not occur, the thread will remove the object holder from the AOM and delete it when etherealize returns. Request processing is the normal case; it is the most common scenario, and must be made highly efficient. Although the efficiency of this scenario can be determined from the above descriptions and state diagram, the following pseudo-code further illustrates the point:
- ServantActivatorlnterceptor :dispatch
- entry state is TERMINATING or entry state is TERMINATING_WITH_ACTIVATION
- entry reference count is 0
- POA deactivate . . . . obj ect.
- Deactivation only occur if the object is in the Available state. Attempts to deactivate an object in the Start, Incarnating, Etherealizing or Reincarnating state result in OBJECT_NOT_EXIST, and attempts to deactivate an object in the Deactivating state are ignored (i.e. the deactivation has already started, but has not yet completed). If the object is Available state, deactivation may not be able to proceed immediately if there are method requests in progress on the servant (i.e. the reference count is non-zero). In this case, we transition to the Terminating intermediate state; when the last in-progress request completes, the current servant generation will be etherealized. Refer to Post Dispatch Processing, discussed below, for more detail.
- the POA of the present invention preferably supports three options for request processing during deactivate: delivery, holding, and discarding. The mechanism used to choose between these options is described in [POAREQ]; this section simply describes the behavior of the POA during
- DELIVER The POA will continue to deliver request as long as the object is deactivating. When no more requests are executing, the object will transition from Deactivating to Etherealizing. Refer to Post-Dispatch Processing discussed below for more information.
- DISCARD - The POA will allow requests currently in user code to complete, but will throw the TRANSIENT exception if new requests arrive for the object while it is Deactivating. Requests will continue to hold if they arrive while the object is Etherealizing.
- Object reactivation occurs when a method or activation request arrives while an object is being etherealized, or if the object is deactivating with the HOLD request processing option. Effectively, object reactivation waits for the current servant to be fully etherealized, then activates a new servant for the object. To perform object reactivation, the thread making the request increments the reactivation count - indicating that it is waiting for a new servant generation. It then waits until the current servant generation is Reincarnating.
- the thread performing the etherealization checks the reactivation count. If this count is non-zero, there are other threads waiting for the etherealization to complete.
- the etherealizing thread changes the state to Reincarnating, then broadcasts the condition variable to wake the blocking threads. The first thread woken will see that the object's state is Reincarnating, and will perform the steps needed to reactivate the servant, for example, if the thread was in the process of method dispatching, it will call ServantActivator : : incarnate to create a new incarnation.
- the thread also sets the reference count to the reactivation count, and clears the reactivation count; this ensures that all waiting threads waiting have a chance to use the new generation.
- This Active Object Map Since this Active Object Map does not directly correspond to the AOM used in this design, some care needs to be taken to ensure that operations defined using the POA AOM function correctly.
- the view taken here is that an object is considered to exist in the POA AOM when it is Available or Terminating.
- the one exception to this rule is the activate object call; this call considers an object to exist when it is Available, Terminating, or Incarnating.
- auxiliary objects a daemon proxy, a persistent POA registry, and a activator registry.
- the daemon proxy represents the server's connection to the location daemon - it is created on demand the first time a persistent POA is created or an Adapt erAct ivator is registered.
- the endpoint state objects are maintained in a special transient POA
- the binding manager looks for a binding using the object key in the request.
- the key for objects implemented in the POA is endpoint - id : FQPN : oid and the key used by POAs to register with the binding manager is endpoint - id : FQPN. This makes the FQPN the distinguishing segment of the object key - if an entry does not exist for a particular FQPN, the request cannot be dispatched.
- TRANSIENT POAs can exist in only one process, and at only one time. Failure to find the binding for a TRANSIENT POA indicates that the POA no longer exists, and consequently the object no longer exists. To handle this, we rely on the default behavior of the binding manager, which returns OBJECT_NOT_EXIST to the client.
- PERS I STENT POAs are very different - a PERS I STENT POA can live across processes. Consequently, failure to find the binding for a PERSISTENT POA may simply indicate that the POA resides within another process, and that the client should contact the daemon in order to locate the POA.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Warehouses Or Storage Devices (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU28609/00A AU2860900A (en) | 1999-01-29 | 2000-01-28 | Method and system for multi-threaded object loading and unloading |
US09/890,444 US6957436B1 (en) | 1999-01-29 | 2000-01-28 | Method and system for multi-threaded object loading and unloading |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11794599P | 1999-01-29 | 1999-01-29 | |
US60/117,945 | 1999-01-29 | ||
US12655499P | 1999-03-26 | 1999-03-26 | |
US60/126,554 | 1999-03-26 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO2000045239A2 true WO2000045239A2 (en) | 2000-08-03 |
WO2000045239A3 WO2000045239A3 (en) | 2001-02-01 |
WO2000045239A9 WO2000045239A9 (en) | 2001-08-30 |
Family
ID=26815826
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/002015 WO2000045239A2 (en) | 1999-01-29 | 2000-01-28 | Method and system for multi-threaded object loading and unloading |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU2860900A (en) |
WO (1) | WO2000045239A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001014959A2 (en) * | 1999-08-16 | 2001-03-01 | Z-Force Corporation | System of reusable software parts and methods of use |
JP2002149425A (en) * | 2000-10-30 | 2002-05-24 | Microsoft Corp | System and method for quickly referring to reference counted item |
WO2006058242A3 (en) * | 2004-11-24 | 2006-10-19 | Mobilygen Corp | Hardware multithreading systems and methods |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5630136A (en) * | 1995-06-09 | 1997-05-13 | Sun Microsystems, Inc. | Method and apparatus for serializing access to multithreading unsafe resources |
-
2000
- 2000-01-28 WO PCT/US2000/002015 patent/WO2000045239A2/en active Application Filing
- 2000-01-28 AU AU28609/00A patent/AU2860900A/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5630136A (en) * | 1995-06-09 | 1997-05-13 | Sun Microsystems, Inc. | Method and apparatus for serializing access to multithreading unsafe resources |
Non-Patent Citations (1)
Title |
---|
GLASSER DANIEL: 'Efficient synchronization techniques for multithreaded win32-based applications' MICROSOFT SYSTEM JOURNAL no. 2, February 1995, page 38 PAGES, XP002931632 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001014959A2 (en) * | 1999-08-16 | 2001-03-01 | Z-Force Corporation | System of reusable software parts and methods of use |
WO2001014959A3 (en) * | 1999-08-16 | 2002-11-07 | Force Corp Z | System of reusable software parts and methods of use |
JP2002149425A (en) * | 2000-10-30 | 2002-05-24 | Microsoft Corp | System and method for quickly referring to reference counted item |
EP1202179A3 (en) * | 2000-10-30 | 2008-01-16 | Microsoft Corporation | System and method for fast referencing a reference counted item |
WO2006058242A3 (en) * | 2004-11-24 | 2006-10-19 | Mobilygen Corp | Hardware multithreading systems and methods |
US7765547B2 (en) | 2004-11-24 | 2010-07-27 | Maxim Integrated Products, Inc. | Hardware multithreading systems with state registers having thread profiling data |
US8640129B2 (en) | 2004-11-24 | 2014-01-28 | Geo Semiconductor Inc. | Hardware multithreading systems and methods |
Also Published As
Publication number | Publication date |
---|---|
AU2860900A (en) | 2000-08-18 |
WO2000045239A9 (en) | 2001-08-30 |
WO2000045239A3 (en) | 2001-02-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6260077B1 (en) | Method, apparatus and program product for interfacing a multi-threaded, client-based API to a single-threaded, server-based API | |
US6282568B1 (en) | Platform independent distributed management system for manipulating managed objects in a network | |
US6671686B2 (en) | Decentralized, distributed internet data management | |
US6185609B1 (en) | Method, apparatus and program to provide client access to a management information service residing on a server in a computer network system | |
Balter et al. | Architecture and implementation of Guide, an object-oriented distributed system | |
US20020004848A1 (en) | System and method of providing an asynchronous interface between a client system and an enterprise javabeans-enabled server | |
US6438616B1 (en) | Method and apparatus for fast, local corba object references | |
US7233972B2 (en) | Method and apparatus for coordination of client/server processes | |
US20040205771A1 (en) | System and method of generating and using proxy beans | |
WO2004003685A2 (en) | Systems and methods for maintaining transactional persistence | |
WO2000010080A1 (en) | Queued method invocations on distributed component applications | |
US6205491B1 (en) | Method and apparatus for deferred throwing of exceptions in C++ | |
US7562369B1 (en) | Method and system for dynamic configuration of activators in a client-server environment | |
US6957436B1 (en) | Method and system for multi-threaded object loading and unloading | |
WO2000045239A2 (en) | Method and system for multi-threaded object loading and unloading | |
JP2000003288A (en) | Method and device for compelling locked invariable in multi-thread system | |
Stal | Component technologies for the middle tier: CCM, EJB, COM‡ | |
Stal | Effective Architectures for Distributed Object Computing | |
Janson et al. | CORBA vs. DCOM | |
Yao | A Java implementation of a Linda-like Tuplespace system with nested transactions: a thesis presented in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University, Albany, New Zealand | |
Stal et al. | Efficient Architectures for object-oriented component-based Middleware | |
Yao | A Java Implementation of a Linda-like Tuplespace System with Nested Transactions | |
Mencnarowski et al. | Active Badge {next generation version 0.9 Implementation Description | |
Mor | X Session Management Library | |
Tutorial | 7KH $ GDSWLYH &RPPXQLFDWLRQ (QYLURQPHQW $ & (µ |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
AK | Designated states |
Kind code of ref document: C2 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C2 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
COP | Corrected version of pamphlet |
Free format text: PAGES 1/5-5/5, DRAWINGS, REPLACED BY NEW PAGES 1/7-7/7; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 09890444 Country of ref document: US |
|
122 | Ep: pct application non-entry in european phase |