CMPI中的内存管理及在Open Pegasus 中的实现

    本文首先简单介绍了 CMPI（Common Manageability Programming Interface） 规范与 Open Pegasus， 说明了 CMPI 规范中对多线程及内存管理方面的要求，然后以 Open Pegasus 中的实现为例，分析了为实现上述要求所需要的关键数据结构，最后全文进行了总结。

    CMPI（Common Manageability Programming Interface） 是由 Open Group（www.opengroup.org） 维护的一套规范。其中定义了一系列基于C语言的编程接口。基于这些编程接口， CMPI 隔离了 CIMOM（CIM Object Manager， 又称 Management Broker ）和 CIM Provider （又称 Management Instrumentation， 以下简称 Provider ）中的相关实现，从而使 Provider 的开发和运行不再依赖于某种特定的 CIMOM。 因此无需重新编译链接， Provider 可以发布到任何一种支持 CMPI 的 CIMOM 中。

    Open Pegasus（www.openpegasus.org， 以下简称 Pegasus ）是一个开源的企业级的 CIMOM。它实现了对 CMPI 规范的支持。本文就以 Pegasus （2.7.1版）为例，研究了 CMPI 实现中的多线程内存管理的问题。

    本文讨论的默认平台为 Linux。

    CMPI 中的线程与内存问题

    CMPI 需要同时解决的两个问题就是其所驱动的 Provider 代码的线程安全与可重入性以及 CMPI 对象的内存管理。

    线程安全及可重入

    CMPI 规范要求 CMPI 的实现是线程安全以及是可重入的。这是因为通常 CIMOM 为了同时响应多个 CIM 的请求，会为每个 CIM 请求生成一个线程。这些线程通过 CMPI 定义的接口来驱动 Provider 的代码。因此同一段 Provider 的代码可能同时被多个线程所执行。为了达到线程安全及可重入，CMPI 规范中提出需要实现一个 CMPI 上下文（ CMPIContext ）的对象。每个线程拥有不同的 CMPIContext 对象，所有静态的数据都将存储在这个上下文对象之中，从而实现线程相关数据的分离。

    内存管理

    因为 CMPI 对象相对复杂，为了保证内存性能， CMPI 规范中规定了在 Provider 调用期间所有通过 CMPI 进行的内存分配（除了使用 CMPI 中定义的 clone 方法申请的内存）都应当由 CMPI 负责释放。这极大的降低了 Provider 编程中对内存管理编程的复杂度，使遵守 CMPI 规范的 Provider 开发更简单。但是也正是因为 CMPI 能自动管理内部使用的 CMPI 对象，因此如果希望一个 CMPI 对象的作用域能够超出其所在函数的范围，就必须使用 CMPI 为每个 CMPI 对象定义的 clone 方法。使用 clone 方法创建的 CMPI 对象，脱离了 CMPI 的管理，因此需要显式调用该对象的 release 方法进行释放。

    Pegasus 中对 CMPI 多线程内存管理的实现

    作为企业级的 CIMOM 实现， Pegasus 为了能够在多线程的环境下实现内存的管理，实现了若干数据结构。图1给出了这些数据结构的关系图。

    图 1：Pegasus 中支持 CMPI 的相关数据结构

    其中关键的数据结构是 CMPI_ThreadContext 。 Pegasus 在启动每个响应 CIM 请求（例如 EnumerateInstances ）的线程时，都会在栈上生成一个 CMPI_ThreadContext 对象，以维护对该 CIM 请求的处理过程中动态创建的 CMPI 对象。因为其是在栈上创建的，因此当其作用域退出时，该对象及其管理的所有 CMPI 对象也会随之析构。

    一般来讲，一个线程只需要一个 CMPI_ThreadContext 对象就可以完成管理其生命周期内所有 CMPI 对象的任务。

 [2] [3] 下一页