System and method to synchronize two or more object management systems

A distributed reader and writer's lock to synchronize object management systems is disclosed. The purpose of the lock is to control access to information that is shared by corresponding object management system components on multiple object management systems. An object management system is a computer-based system for storing, naming, and manipulating objects. One lock is created for each object management system component associated with a particular service within the system. The locks communicate over an interface definition language interface. The reader/writer's lock is created by a remote component synchronization module, which acts as an agent for the object management system component. The lock exposes functions to request or release a write lock and to request or release a read lock.

BACKGROUND

1. Technical Field

Embodiments described herein are directed to a distributed reader and writer's lock to control access to information shared by corresponding object management system components on multiple object management systems. An object management system is a computer-based system for storing, naming, and manipulating objects. One lock is created for each object management system component that is associated with a particular service in the system. The locks communicate with an interface definition language or similar language.

2. Related Art

At present, multiple processes are synchronized on a single network processor running the Intel® Internet Exchange Architecture (“IXA”) object management system. Intel® IXA is a packet processing architecture that provides a foundation for software portability across multiple generations of network processors. Intel® IXA focuses on Intel® network processors and is based on microengine technology, the Intel® XScale™ microarchitecture and the Intel® IXA Hardware Abstraction Layer.

Through Intel® IXA, a greater choice of standards-based, high performance communications building blocks is made available. These building blocks provide faster time-to-market, greater design flexibility and extended time-in-market for next-generation networking solutions. Intel® IXA empowers more rapid deployment of differentiated, reliable and intelligent services for the converged Internet Protocol network, while maximizing return on capital investment.

There exists, however, a legitimate business need for an approach which provides an object management messaging system that allows tasks and high-level programming frameworks such as the Active Computing Element (“ACE”) to send messages to one another on multiple network processors in the same manner as they would on a single network processor. Such an approach is beneficial for users who intend to write IXA applications to run on multiple network processors.

In addition, with such an advancement in the field, users who develop applications for a single network processor will be able to upgrade to using several processors without having to rewrite any of the object management system messaging code. This approach is not limited to Intel® architectures; it may also be implemented on other non-Intel® related architectures.

DETAILED DESCRIPTION

The following paragraphs describe a distributed reader and writer's lock100for synchronizing object management systems. An object management system is a computer-based system for storing, naming, and manipulating objects. The distributed reader and writer's lock100is one component in the synchronization system of a multiple object management system. The purpose of the distributed reader and writer's lock100is to control access to information shared by corresponding object management system components140on multiple object management systems. One distributed reader and writer's lock100is created for each object management system component140associated with a particular service within the system.

According to one embodiment of the present invention, as illustrated in FIG.1andFIG. 2, the distributed reader and writer's lock100communicates over an interface definition language interface110or similar language interface. A remote component synchronization module120creates the distributed reader and writer's lock100. The remote component synchronization module120acts as an agent for the object management system component140. The distributed reader and writer's lock100exposes functions to request a read lock200and release a read lock200and to request a write lock210and release a write lock210.

As seen from a system perspective, one remote component synchronization module120may have one write lock210at a time, although it may have several read locks200. The write lock210is only granted to the remote component synchronization module120when all outstanding read locks200are released, and all outstanding read lock200requests are granted and released. The remote component synchronization module120that has the write lock210may acquire one or more read locks200, but read lock200requests are blocked for other remote component synchronization modules120until the write lock210is released. In the absence of a write lock210, any remote component synchronization module120may acquire one or more read locks200.

The distributed reader and writer's lock100communicates with corresponding locks on other object management systems through ix_ring objects, which function as ring buffers. The code that marshals the message data and that sends and receives data from the rings is interface definition language110generated. The code encapsulates the ix_ring and interface information into an ix_base t object220.

In the Internet Exchange Architecture (“IXA”) system, the functions that support incoming messages are known as skeleton functions, while those that support outgoing messages are referred to as stub functions. A single interface definition language interface110uses only one ix_base_t object220to support the skeleton interface and one ix_base_t object220for each connected object management system to support the stub interface.

The distributed reader and writer's lock100manages the ix_base_t object220that handles the skeleton interface. The distributed reader and writer's lock100offloads management of the stub interface to a list controller130and provides two callback functions while registering as a client of the list controller130. The creation and partial initialization of an ix_base_t object220as a stub interface to a new object management system being connected to the system is one such function. The initialization is performed by the interface definition language110generated stub initialization function. The other function is the clean up and destruction of an ix_base_t object220when an object management system is disconnected from the system. The clean up is performed by the interface definition language110generated stub clean-up function. The distributed reader and writer's lock100does not track the active ix_base_t objects220because the list controller130provides a function to iterate through all of the lock's current ix_base_t stub objects. The list controller130further maintains a communications list150and is connected to the communications controller160. The Application Program Interfaces (“API”) presented to the remote component synchronization module120are synchronous. APIs are sets of routines, protocols, and tools for building software applications. An API thus serves as a programmatic interface for interprogram communications or for interfacing between protocol layers.

When the remote component synchronization module120makes a read200or write lock210request, the function does not return until the lock is acquired. Since all incoming messages are received in the same ix_base_t object220, including replies to requests sent by the local object management system, the skeleton code must not block for an indeterminate period. Because of this, the distributed reader and writer's lock100runs the skeleton code in a separate thread. Using a thread protection mutex in the skeleton code is acceptable, whereby the mutex is a program object that allows multiple program threads to share the same resource, but not simultaneously.

A remote object management system may request a write lock210when the local object management system has a read lock200. An object management system does not know of the status of read locks200on other object management systems. Since the time that a read lock200may be held is undetermined, it follows that the skeleton code cannot be synchronous. That is, if a write lock210request is received from another object management system, the skeleton code may not wait until the read lock200is released. Thus, the local object management system must respond with a callback to the requesting object management system when the lock becomes available.

Each distributed reader and writer's lock100module contains a reader and writer's lock component, wherein the write lock210may be adjusted through the interface definition language interface110. That is, only a remote module may set the lock, and a separate variable maintains the state of the local write lock210. The reason for this is that the module must grant local read locks200if the write lock210is local, yet read lock200requests are blocked if a remote module has the write lock210.

Algorithms are employed to describe the main flow only. For instance, timeout handling is not shown. Wherever a timeout can occur, a step is repeated up to the number of retries set during initialization. Should a timeout still occur, the function returns with a timeout indicator set. If the function detects an error, it returns the error to the remote component synchronization module120that is using the standard ix_error encapsulation facilities provided by an action services library.

FIG. 2illustrates the distributed reader and writer's lock100function interface. It depicts the read lock200request, read lock200release, write lock210request, and write lock210release as originating at the remote component synchronization module120and extending to the distributed reader and writer's lock100. A lock create and lock destroy similarly originate at the remote component synchronization module120and extend to the distributed reader and writer's lock100into the interface definition language interface110. The create ix_base_t220function and the destroy ix_base_t220function are shown as stemming from the list controller130to the distributed reader and writer's lock100into the interface definition language interface110. From the distributed reader and writer's lock100to the list controller130, extends the register callbacks function and the iterate ix_base_t objects220function. In addition, the interface definition language interface110receives messages from other locks as well as sends messages to other locks.

FIG. 3shows the operations involved in making a local write lock210request. If a write request is already pending, as questioned in operation300, the system must wait until its pending status drops, as depicted in operation305, and then increment the pending semaphore and continue, as shown in operation310. That is, the semaphore operates as a variable with a value that indicates the status of common resource. It locks the resource that is being used. The process needing the resource checks the semaphore to determine the resource's status and then decides how to proceed. As described in operation315, if the local module already has the write lock210, then the system increments a local write lock210count. If the write lock210is set by another object management system, the system must wait, as illustrated in operation320, for it to be released. If an object management system has just released its local lock and is in the process of sending the release to remote object management systems, as shown in operation325, the system must wait until the release option is complete. A clear-pending lock is employed here. Next, as depicted in operation330, the lock contention mutex is locked and a random number is created for resolving write lock210contention. As shown in operation335, the system then checks a variable dedicated to write lock210arbitration counting. If the value is greater than zero, a request has been received by a remote object management between operations320and325. As such, the lock contention mutex is released and the flow returns to operation320. Otherwise, the arbitration count is incremented, as illustrated in operation350. As described in operation355, the lock's210arbitration identification is set to the local object management system identification. Its priority is also set through the generation of a bound random number. The lock contention mutex is then released, as shown in operation360. For each connection returned through an iterator provided by the list controller130, a write lock210request is made to the remote reader and writer's lock, as illustrated in operation365. Operation370then examines whether the request failed. If a request fails because of contention in a remote module, the local write lock count is decremented, as shown in operation375, and the process repeats from operation320, as shown in operation380. Instead of creating a new random number for resolving write lock210contention, the request's priority is bumped beyond the upper boundary of the random number range. This guarantees that requests re-entering arbitration are afforded higher priority than new requests. The size of the random number generation range must be low enough to allow the arbitration to bump several times without integer overflow; enough to accommodate the maximum size of the pending request queue. If the request did not fail, as depicted in operation385, when all remote modules have provided the write lock210to the requesting module, the process returns without setting the write lock210in the lock component. This allows the local module to grant read locks200.

FIG. 4shows the operations involved in making a local read lock200request. This function does not result in any request being passed over the interface definition language interface110. The algorithm is as follows. As shown in operation410, the request is sent to the local lock component. Operation420then examines whether a remote module owns the write lock210. If a remote module does not own the write lock210, the lock is granted, as shown in operation430. If a remote module owns the write lock210, as depicted in operation440, the write lock210is blocked. Operation450shows that the request is then retried. If the available time for the request expires, as illustrated in operation460, the process repeats until the maximum number of retries is reached.

FIG. 5shows the operations involved in making a remote write lock210request. This request is received over the interface definition language interface110. Each lock module is responsible for ensuring that it never sends a request to remote object management systems if it already owns the write lock210. Therefore, more than one call to this function without an intervening release of the write lock210will only occur during write lock210contention. This allows the ownership of the write lock210to be changed during the write contention interval, where the write contention interval is, the time it takes for the requesting module to be granted the write lock210by all other modules.

As shown in operation510, the lock contention mutex is locked, and the arbitration count is checked. Operation520examines whether this value is greater than zero. If the value is not greater than zero, the count is incremented, as illustrated in operation530. If the value is greater than zero, a request has been previously received. The contention for the write lock210must thus be resolved, as shown in operation540. The resolve write lock contention function is called when a remote object management system requests a write lock210, yet the write lock210contention variables, priority and identification, have either been set by a local request or by a previous invocation of the write lock210arbitration function.

The write lock210arbitration function assumes that a write lock210contention mutex has already been locked by the time that it has been called and that it will be unlocked after the function has returned. The arbiter examines the values of priority and identification. If the requested priority is different than the current priority, the arbitration winner is decided by priority. Otherwise, the arbiter decides the winner based on object management system identification. It is required that each object management system in a multiple object management system has a unique identification. If the arbitration winner is the remote object management system, the contention variables in the local lock are changed, and the arbitration fields passed by the remote object management system are returned unchanged. In contrast, if the object management system already specified in the local arbitration prevails, the local variables are left unchanged, and the arbitration fields are fixed to the values in the local variables.

Operation550examines whether the remote object management system prevailed in arbitration. As shown in operation560, if the remote object management system loses arbitration, the lock contention mutex is released and information about the arbitration winner to the requesting object management system is returned. Otherwise, as illustrated in operation570, the request is sent to the lock component, which will block until all outstanding read locks200are released. The lock contention mutex is then released, as depicted in operation580. The operations outlined above cannot be executed in one function because remote requests are received in the interface definition language skeleton code, which must not block for an indeterminate period. Therefore, the incoming request must be asynchronous to the reply.

FIG. 6shows the operations involved in a local write lock210release. As shown in operation610, a clear pending lock is set to prevent the local object management system from processing another request until the current lock has been released from all remote object management systems. The write lock210contention mutex is then locked and the write lock210count is decremented, as illustrated in operation620. Operation630then examines whether the write lock210count is zero. If the write lock210count is zero, as shown in operation640, the write lock210contention variables, identification and priority, must be cleared. Otherwise, some other module on the local object management system has a write lock210. In that case, the lock contention mutex must be released, as depicted in operation650. Operation660describes the calling of the write lock210release functions on remote modules over the interface definition language interface110. This is achieved in two stages—one to clear the arbitration variables in the remote object management systems and one to enable arbitration for the next request. Otherwise, in a system of three or more object management systems, a remote object management system could arbitrate against stale arbitration values. The clear pending lock is then released, as shown in operation670.

In an alternative embodiment, the local write lock210count and arbitration count can be combined into one variable. That is, the skeleton write lock210release code can be consolidated into a single stage process, thereby reducing inter-object management system message traffic. This version requires the lock to keep the history of the arbitration variables for the last owner of the write lock210. The arbitration function would require that if the same object management system is re-arbitrating for the lock after having owned the previous lock, then the random number it uses to generate its arbitration priority may not be the same as the number it used previously. During arbitration, an object management system can detect that the arbitration variables are stale and adjust the arbitration and write lock210state accordingly. This optimization is complicated by the notion that the write lock210release for the old lock and the next request may appear out of order if there are more than two object management systems. If the code is not written carefully, an object management system receiving out of sequence release and request messages would be excluded from the opportunity of participating in the arbitration contest.

FIG. 7shows the operations involved in a remote write lock210release. As explained in the preceding section, this activity occurs in two stages. First, as described in operation710, the clear pending lock is set to prevent the local object management system from processing another request until the current lock has been released from all remote object management systems. The write lock210contention mutex is then locked and the write lock210contentions variables, write identification and priority, are cleared, as shown in operation720. The writer's lock210is then cleared from the local lock component, as illustrated in operation730. The lock contention mutex is released, as described in operation740. In the second stage, the clear pending lock is cleared, as shown in operation750. The second stage occurs after the owner of the write lock210on all connected object management systems has performed the first stage.

While the above description refers to particular embodiments of the present invention, it will be understood to those of ordinary skill in the art that modifications may be made without departing from the spirit thereof. The accompanying claims are intended to cover any such modifications as would fall within the true scope and spirit of the embodiments of the present invention.

The presently disclosed embodiments are therefore to be considered in all respects as illustrative and not restrictive; the scope of the embodiments of the invention being indicated by the appended claims, rather than the foregoing description. All changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.