PARALLEL EXECUTION OF REQUESTS IN OSI AGENTS

Abstract: This invention concerns a method for organizing the execution of Common Management Information Protocol (CMIP) requests in an Open Systems Interconnection (OSI) environment by providing main threads (24) and sub-threads (27, 28) within each main thread for simultaneous processing of multiple CMIP requests. In brief, a main thread (24) is started sequentially for executing incoming CMIP requests, the main thread checks whether a particular managed objects (20, 21) is available, i.e. not locked, locks it, and starts a sub-thread to process the CMIP request in this managed object. This allows the main thread to start another sub-thread, thus providing for the parallel execution of a plurality of CMIP requests.

Description: DESCRIPTION Parallel Execution of Requests in OSI Agents The present invention is concerned with the handling of Common Management Information Protocol (CMIP) requests in an Open Systems Interconnection (OSI) environment, and in particular with the execution of such CMIP requests in so-called OSI agents when several requests are received or pending concurrently. BACKGROUND The OSI (Open Systems Interconnection) systems management is a standard that provides mechanisms for the monitoring, control, and coordination of resources such as storage units, databases, telecommunication switches, communication links, etc., within the OSI environment and OSI protocol standards for communicating information pertinent to those resources. The OSI management standards define an "agent" as an application entity that provides a standardized access to a resource, and a "manager" as an application entity that performs management functions. A resource is represented using standardized "managed object classes" and each instantiation of a class is called a "managed object instance". For example, one managed object class may be a generally defined type of disk unit, and each individual disk unit of that type then is one instance of this class. The various operations in such a system are governed by a "Common Management Information Protocol" or short CMIP. A manager application executes management operations on managed object instances contained in an agent by sending CMIS (Common Management Information Services) service requests to that agent over the network using the CMIP protocol. Such service requests may include the following operations: create, delete, set, get, action, cancel-get. The agent returns responses and events to the manager, also using the CMIP protocol. The configuration of such an OSI environment is shown generally in Fig. 1 , including, besides the communication network 1 , an OSI manager 2, OSI agent 3 with agent kernel 4, managed object instances 5-a, 5-b, 5-i, 5-n, resources 6-a, 6-b to be accessed, and the flow of CMIP protocol messages. The OSI Systems Management standards and the related CMIP protocol and CMIS services are described in the following publications: - ISO/IEC 10040, Information Technology - Open Systems Interconnection - Systems Management Overview, 1991. - ISO/IEC 9595, Information Technology - Open Systems Interconnection - Common Management Information Service Definition, 1991. - ISO/IEC 9596, Information Technology - Open Systems Interconnection - Common Management Information Protocol Definition, 1991. - ISO/IEC 10165-1 , Information Technology - Open Systems Interconnection - Structure of Management Information - Part 1 : Management Information Model, 1992. - ISO/IEC 10165-2, Information Technology - Open Systems Interconnection - Structure of Management Information - Definition of Management Information, 1992. — ISO/IEC 10165-4, Information Technology - Open Systems Interconnection - Guidelines for the Definition of Managed Objects, 1992. Multiple managers can be connected to an agent at the same time, and each can send CMIP requests to the agent asynchronously. This results in the following problem: An OSI agent can receive multiple CMIP requests from multiple sources. Some of these requests may incur long processing times — a typical example is a CMIP "get" request to a managed object instance which may result in a resource access (establish connection, wait for response, close connection). Servicing CMIP requests sequentially may therefore cause long delays and thus may result in poor performance. Some help in the organization of servicing requests and accessing resources may be the use of "threads", a thread being a single flow of control within a process, each thread having its own thread identifier (ID) and the required resources to support a flow of control. In this context, a function is provided called "mutex" (mutual exclusion) which allows multiple threads to serialize their access to shared data; a thread can lock a mutex and thereby becomes its owner until that same thread unlocks the mutex. A description and definition of threads are given in the following publications: - A.Birrell: "An Introduction to Programming with Threads", in "Systems Programming with Modula-3", G. Nelson (Ed.), Prentice Hall, 1991 , pp. 88-118; - Draft Standard for Information Technology - Portable Operating System interface (POSIX) - Part 1 : Systems Application Program Interface (API), Amendment 2: Threads Extension; IEEE, October 1993. - U.S.Patent 5 247 676 "RPC Based Computer System Using Transparent Callback and Associated Method", disclosing a first calling thread, a second called thread, and helper threads- However, this patent concerns remote procedure calls (RPCs) and callbacks within a computer system, and not the problem of handling multiple CMIP requests in an OSI environment. The utilization of threads and the mutex function as presented in the prior art do allow serialization of accesses but per se do not solve the above stated problem of possible long delays and poor performance when multiple CMIP requests are received and resources have to be accessed. OBJECTS OF THE INVENTION It is therefore an object of the invention to devise a method for the execution of CMIP requests which allows the handling of multiple CMIP requests by an agent without undue delays. It is a further object to provide a method for CMIP request execution which uses threads but avoids the disadvantages incurred when the locking of objects result in long delays due to mutual exclusion. These and other objects are achieved by the method defined in the claims. An embodiment of the invention is described in the sequel with reference to following drawings. LIST OF FIGURES Fig. 1 is a schematic representation of an OSI environment including at least one manager, at least one agent with managed objects, resources, and CMIP protocol flows between a manager and an agent; Fig. 2 is a flow diagram of the method as invented, showing the operations in the main thread and in sub-threads; Fig. 3 is a schematic block diagram showing the interaction of various portions of an OSI agent in which the invention is used; Fig. 4 is a block diagram of a particular example of an OSI system in which the invention is used; and Fig. 5 is a schematic diagram showing the interaction of multiple sub-threads as well as an example of the object table used by threads in the agent. DETAILED DESCRIPTION Basics of the Invention Details of the invention are now described in connection with Figs. 2 and 3. Fig. 2 is a flow diagram illustrating the operations performed in an OSI agent when handling CMIP requests, and Fig. 3 shows .the interaction of different portions of an OSI agent for CMIP request handling. The gist of the invention is as follows. Each agent has a "main thread" that is always active and performs a message dispatching function. It reads messages from the network, and extracts messages (if any) from an internal request queue that is provided for the main thread. For each CMIP request that is to be executed in the agent, a separate sub-thread is started. In order to prevent access to a managed object instance by more than one sub-thread, each managed object instance has a lock. An object instance is locked for one sub-thread as long as the respective CMIP request is executed, and is unlocked when processing is complete. Note that below and in the claims, the term "object" is used for designating a "managed object instance". The following procedures are performed in an agent (cf. Fig.2). A. Basic Procedure for the Main Thread: 1. Check whether there are any messages in the queue. For each message in the internal request queue, perform procedure B described below. If there are no messages queued, proceed to step 2. 2. Wait for a CMIP request from the network. When a message is received, perform procedure B described below, and then go back to step 1. B. Request Handling Procedure for the Main Thread: 1. If the request is a CMIP Create, go to step 3. Otherwise, check whether the destination object is locked. If object is unlocked, continue with step 2. If locked, place message into the internal request queue (and return to procedure A). — Note that in the last step, either a message previously extracted from the internal request queue is put back into the queue, or a message newly received from the network is placed newly into the queue. 2. Lock object. 3. Start sub-thread. 4. Return to procedure A. C. Procedure for Sub-Threads: 1. Register sub-thread and the object it is working on with the thread manager. 2. Process request. 3. If request is NOT CMIP Create, induce main thread to unlock object. 4. Terminate sub-thread, de-registering it from the thread manager. Fig. 3 shows different portions in one OSI agent and their interaction. A main thread 7 is provided for handling CMIP requests received from the communication network on input 8, or CMIP requests that are temporarily stored in request queue 9. The CMIP requests are to be processed in managed objects 10-1 ... 10-i ... 10-n, which in turn are connected to resources (storage units, switches, etc.). Thread manager 7 maintains an object table 11 in which each active managed object is registered. As can be seen from the block diagram of Fig. 3, a "thread manager" 12 is provided in each OSI agent to keep track of the active sub-threads and the objects each thread has locked and not yet unlocked (released). For this purpose, a "thread information table" 13 is maintained which lists for each active thread any object that the said thread has locked. By this, it can also be prevented that a sub-thread attempts to lock an object which was already locked for itself. (Cf. also details in the later section on "multithreading".) The locking status of each object is maintained in the "object table" 11 shown in Fig. 3. This table contains a list of all objects present in the agent. For each object entry in the table, the locking status of the object (locked/unlocked) is indicated. A new entry is added to the object table when an object is created. Likewise, when an object is deleted from the agent, the corresponding entry in the object table is aiso deleted. The reason for NOT locking a managed object when the request is a CMIP Create is simply because the Create request is not directed at an object, but rather instructs the agent to create one. After the creation of the object, other CMIP operations can be sent to this object, and for those operations, the object will have to be locked. OSI System Management Example One specific example of an application of the invention is now described in connection with Fig. 4. The purpose of this example is to illustrate a simple case of OSI systems management where two disk drives have to be managed. For the purpose of the example, the disk drives are assumed to be "intelligent", i.e. each is equipped with processing capability to check consistency of its contents on command. Fig. 4 shows the configuration of the system. This configuration includes OSI manager 14, OSI agent 15 with managed objects 16, 17 and, as resources, disk drives 18, 19 (disk-1 and disk-2). As required by OSI, an object class is defined to represent or model a disk drive. Using OSI formalism (GDMO and ASN.1), an object class "disk" can be defined as follows (unnecessary details omitted): disk MANAGED OBJECT CLASS DERIVED FROM top; ATTRIBUTES checkdisk GET-REPLACE REGISTERED AS {1 3 18 0 24 5 1j ; checkdisk ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER; BEHAVIOUR checkdiskBehaviour BEHAVIOUR DEFINED AS "When set to 1, it will perform disk consistency check . and then sets its value to the number of bytes scanned";; REGISTERED AS [1 3 18 0 2 4 6 1} . The two disk drives in this case, disk-1 and disk-2, are represented in the OSI agent by two instances of the "disk" managed object class. When the attribute "checkdisk" for a "disk" instance is set to a value of 1 , a command is sent to the actual disk drive to start the consistency checking operation. The command completes when the check is done, and returns the number of bytes scanned. In other words, an OSI set operation on the attribute will only complete after the consistency check is completed, and will return the number of scanned bytes as the "set" value. In this example, OSI manager 14 sends a single "scoped" CMIP Set request to agent 15, with the instruction to set the value of "checkdisk" attribute to 1 in each instance of "disk" managed object class within the scope. The agent determines the set of instances that fall within the scope (in this example, there are two instances), and issues for each selected instance 16 and 17 the set request, starting each request on a new sub-thread. (Before starting, the agent's main thread checks whether the instance is locked or unlocked). This approach enables both requests to be processed in parallel, i.e. sending the command to disk-1 18 will not block the agent, so that the request to disk-2 19 can also be sent. At the same time, the agent is available to respond to other queries while disk-1 and disk-2 are going through their respective consistency checks. Until the operation is completed, the managed object instances representing disk-1 and disk-2 are locked, and no new CMIP operations on these instances will be permitted to start. When disk-1 and, respectively, disk-2 complete their consistency checks, the responses to the set (including the new value for the checkdisk attribute) will be returned through agent 15 to manager 14 as a response to the original scoped request. The CMIP set request in this case will result in three responses to be returned to the OSI manager as required by OSI: two linked-replies (each containing the value of the set attribute in each disk instance), and an empty set response, indicating the end of response. Multithreading Example Fig. 5 illustrates an example where multiple sub-threads are operating and one sub-thread has to access or use another object during its execution. Fig. 5 is a block diagram of the OSI agent used in this example. It contains three previously created managed object instances, 11 (20), 12 (21), and 13(22). Requests from one or more OSI managers arrive at input 23 of the agent, and are delivered to main thread 24 sequentially in the order they arrive. These messages are read one at a time by the main thread. The lock/unlock status of each instance is kept in object table 25. This table is accessible by any thread active in the agent. Note that a locked managed object instance can only be unlocked by the thread that locked it. In Fig. 5, a code segment 26 is shown from the implementation of instance 11. It is assumed that this segment is executed during the processing of some requests made to 11 . This example code accesses instance 12 (it tries to lock it for access), performs the required operation, on completion, releases (unlocks) instance 12. In the specific example described here, two requests are received by the agent in sequence. The first request, OP1 , is destined for instance 11 ; the second, OP2, is destined for 12. The following steps are executed: - main thread receives OP1 - checks whether 11 is locked: it is unlocked; - locks 11 ; starts sub-thread 27 to process OP1 (sub-thread A) - main thread 24 receives OP2, - checks whether 12 is locked: it is unlocked; - locks 12; starts sub-thread 28 to process OP2 (sub-thread B); - sub-thread A enters the code segment shown in Fig. 5. It attempts to access (lock) 12, but 12 is already locked. Sub-thread A is blocked (temporarily). - Sub-thread B completes processing OP2. It asks main thread 24 to release I2, and terminates; - main thread 24 unlocks 12; - sub-thread A can now proceed (the underlying system unblocks sub-thread A: 12 is now locked for sub-thread A). - At the end of the code segment, sub-thread A releases (unlocks) 12; - sub-thread A completes processing OP1. It asks main thread 24 to release 11 , and terminates. - Main thread 24 unlocks 11. This example makes clear that several requests can be handled simultaneously by separate sub-threads if they work on different managed object instances. However, the locking prevents that on any managed object instance, more than one sub-thread can operate.

Claims: CLAIMS 1. In an OSI (Open Systems Interconnection) system including - at least one OSI manager, - managed objects executing CMIP (Common Management Information Protocol) requests issued by any said OSI manager, and - OSI agents each providing access to plural managed objects, a method for organizing execution of CMIP requests, comprising the following steps: - providing a main thread with each OSI agent for sequentially starting execution of CMIP requests, - for a CMIP request received by an OSI agent, checking by said main thread whether the managed object addressed by said CMIP request is locked and, if the managed object is not locked - locking said managed object, - starting a sub-thread to process said CMIP request with the following steps: - registering said sub-thread and said managed object, - processing said CMIP request, - de-registering said sub-thread, - unlocking said object when processing of said CMIP request is completed, whereby a plurality of CMIP requests can be executed in parallel by simultaneous sub-threads. 2. The method according to Claim 1 , comprising the following additional steps: - providing a thread manager in each OSI agent for administering sub-threads started by said main thread, - said thread manager maintaining a table registering each active sub-thread and any managed object locked for it. 3. The method according to Claim 1 , comprising the following steps: - providing a request queue for the main thread in each OSI agent, and - storing any CMIP request received by the respective OSI agent in said request queue when it cannot be handled immediately. 4. The method according to Claim 3, further including the following step: - if the main thread, when handling a CMIP request, detects that the managed object addressed by said CMIP request is locked, it returns the respective CMIP request into the request queue. 5. The method according to Claim 1 , in which - said CMIP requests include Get, Set, Create, Delete, Action, and Cancel-Get commands, and - if the CMIP request is of the Create command type, the main thread immediately starts a sub-thread for executing the Create request, without intermediate checking and locking steps. 6. The method according to Claim 1 , including the following steps whenever a sub-thread has to access a managed object other than the managed object initially addressed by, and locked for, itself: - checking by the respective sub-thread whether said other managed object is locked, and if it is not yet locked, - locking said other managed object by the respective sub-thread, - executing the required operations in said other managed object, and - unlocking said other managed object by the respective sub-thread.

Inventors: FERIDUN METIN, PARKER DAVID WILLIAM, VAN BERKEL CORNELIS, FERIDUN, METIN, PARKER, DAVID, WILLIAM, VAN BERKEL, CORNELIS
Applicants: IBM, INTERNATIONAL BUSINESS MACHINES CORPORATION
Application year: 1995
Main classification: H04L29
IPC codes: G06F9, G06F13, H04L29