Memory Management in CMPI and Its Implementation in OpenPegasus

Article Title: Memory Management in CMPI and implementation in OpenPegasus. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

This article first briefly introduces the CMPI (Common Manageability Programming Interface) specification and Open Pegasus, describes the requirements for multithreading and memory management in the CMPI specification, and then takes the implementation of Open Pegasus as an example, this paper analyzes the key data structures required to achieve the above requirements, and summarizes the full text.

CMPI (Common Manageability Programming Interface) is a set of specifications maintained by Open Group (www.opengroup.org. It defines a series of C language-based programming interfaces. Based on these programming interfaces, CMPI isolates the implementation in CIMOM (CIM Object Manager, also known as Management Broker) and CIM Provider (also known as Management Instrumentation, hereinafter referred to as Provider, so that the development and running of the Provider no longer depend on a specific CIMOM. Therefore, you do not need to recompile the link. The Provider can be published to any CIMOM that supports CMPI.

Open Pegasus (www.openpegasus.org, hereinafter referred to as Pegasus) is an Open-source enterprise-level CIMOM. It supports CMPI specifications. This article takes Pegasus (version 2.7.1) as an example to study the problem of multi-thread memory management in CMPI implementation.

The default Platform discussed in this article is Linux.

Thread and memory problems in CMPI

The two problems that CMPI needs to solve at the same time are the thread security and reentrant of the Provider code it drives, and the memory management of the CMPI object.

Thread security and Reentrant

The CMPI specification requires that the implementation of CMPI is thread-safe and reentrant. This is because CIMOM usually generates a thread for each CIM request to respond to multiple CIM requests at the same time. These threads use the interfaces defined by CMPI to drive the Provider code. Therefore, the same Provider code may be executed by multiple threads at the same time. In order to ensure thread security and reentrant, The CMPI specification proposes the object that needs to implement a CMPI context (CMPIContext. Each thread has a different CMPIContext object. All static data is stored in this context object to separate thread-related data.

Memory Management

Because the CMPI object is relatively complex, in order to ensure memory performance, the CMPI specification specifies all the memory allocation through CMPI during the Provider call (except for the memory applied using the clone method defined in CMPI) all should be released by CMPI. This greatly reduces the complexity of memory management programming in Provider programming and simplifies Provider development that complies with CMPI specifications. However, CMPI can automatically manage the CMPI objects used internally. Therefore, if you want a CMPI object to be out of the scope of its function, you must use CMPI to define the clone method for each CMPI object. The CMPI object created using the clone method is out of the CMPI management. Therefore, you need to explicitly call the release method of the object for release.

Implementation of CMPI multi-thread memory management in Pegasus

As an enterprise-level CIMOM implementation, Pegasus implements several data structures to implement memory management in a multi-threaded environment. The relationship diagram of these data structures is given.

Figure 1: Related Data Structures supporting CMPI in Pegasus

The key data structure is CMPI_ThreadContext. When Pegasus starts every thread that responds to CIM requests (such as EnumerateInstances), it will generate a CMPI_ThreadContext object on the stack to maintain the CMPI object dynamically created during the process of processing the CIM request. Because it is created on the stack, when its scope exits, the object and all CMPI objects managed by it will also be analyzed.

Generally, a thread only needs a CMPI_ThreadContext object to complete the task of managing all CMPI objects in its lifecycle.

[1] [2] [3] Next page