用一个例子来说明程序开发过程中的粒度和弹性控制

用一个例子来说明程序开发过程中的粒度和弹性控制<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

前言

弹性和粒度是程序开发中的两个重要概念,对这两个方面的控制直接决定一个程序员所能控制的程序的规模.如果粒度太粗,则会倒至模块自身规模太大难以维护.如果粒度太细则模块在复用的时候就会很繁琐.
一个好的思路是将模块的粒度尽量的做的细致,但这些细致的模块有很好的弹性.也就是说虽然粒度很精细但适应能力很强.
下面以一个例子来说明一下上面所说的好思路.这个例子以编程中常见的多线程编程中的临界段来处理来逐步阐述一个好的粒度的弹性控制.

毫无弹性和粒度可言的编程模型.

这个模型以系统提供的临界段编程接口为基础直接使用临界段,不进行任何封装.它的编程模式大致如下:
 

// 全局的临界段声明

CRITICAL_SECTION CriticalSection;

 

void test()

{

 

    // 对临界段进行初始化

     // ** 注意初始化在整个程序期间只需进行一次

    InitializeCriticalSection(&CriticalSection);

 

     // 以函数ThreadProc为入口建立一些线程,或以和函数ThreadProc访问相同共享资源的线程

 

    // 释放临界段

    DeleteCriticalSection(&CriticalSection);

}

 

DWORD WINAPI ThreadProc( LPVOID lpParameter )

{

 

    // 进行入临界段.

    EnterCriticalSection(&CriticalSection);

 

    // 访问共享资源

     // ........

     ///////////

 

    // 离开临界段.

    LeaveCriticalSection(&CriticalSection);

 

     return 0;

 

}

这种编程模式下有一个很不方便的地方,当线程函数ThreadProc有多个return语句时,很容易漏过LeaveCriticalSecton的调用.这会倒至这个临界段所保护的资源再也不能进行访问.

安全使用临界段的类封装(加入些粒度控制)

为了解决漏过离开临界段调用的问题,我们需要一种机制来保证离开临界段的调用,而不是由使用它程序员来负责这个问题.下面是改进后的程序模式:
// 全局的临界段声明

CRITICAL_SECTION CriticalSection;

 

// 保证安全使用临界段的类

struct SafeCriticalSection

{

     SafeCriticalSection()

     {

         // 进行入临界段.

         EnterCriticalSection(&CriticalSection);

 

     }

     ~SafeCriticalSection()

     {

         // 离开临界段.

         LeaveCriticalSection(&CriticalSection);

 

     }

};

 

void test()

{

 

    // 对临界段进行初始化

     // ** 注意初始化在整个程序期间只需进行一次

    InitializeCriticalSection(&CriticalSection);

 

     // 以函数ThreadProc为入口建立一些线程, 或以和函数ThreadProc访问相同共享资源的线程

 

    // 释放临界段

    DeleteCriticalSection(&CriticalSection);

}

 

DWORD WINAPI ThreadProc( LPVOID lpParameter )

{

 

     SafeCriticalSection useCriticalSection;

 

    // 访问共享资源

     // ........

     ///////////

 

 

     return 0;

 

}

在这个模式下,所使用的临界段的EnterCriticalSectoin的调用和LeaveCriticalSectioin的调用被封装在类SafeCriticalSection的构造和析构函数中.使用临界段CriticalSection时再也不用为漏掉对LeaveCriticalSection的调用而小心翼翼了.
到这里我们可以说对临界段CriticalSection的使用有些粒度了.可是这个模式下还有一个不足之处,那就是类SafeCriticalSection与全局变量CriticalSection的联系太紧密了.如果要使用另外一个临界段,我们的类SafeCriticalSection就无能为力了.也就是说这个模式没有弹性.

为粒度加入些弹性

为了让我们的类SafeCriticalSectoin有一定的适应能力我们要为这个类加入一些有弹性的设计.现在的新的程序模式如下:
// 全局的临界段声明

CRITICAL_SECTION CriticalSection;

 

// 保证安全使用临界段的类

struct SafeCriticalSection

{

     SafeCriticalSection(LPCRITICAL_SECTION section):m_critSect(section)

     {

         // 进行入临界段.

         EnterCriticalSection(m_critSect);

 

     }

     ~SafeCriticalSection()

     {

         // 离开临界段.

         LeaveCriticalSection(m_critSect);

 

     }

 

private:

     LPCRITICAL_SECTION m_critSect;

};

 

void test()

{

 

    // 对临界段进行初始化

     // ** 注意初始化在整个程序期间只需进行一次

    InitializeCriticalSection(&CriticalSection);

 

     // 以函数ThreadProc为入口建立一些线程, 或以和函数ThreadProc访问相同共享资源的线程

 

    // 释放临界段

    DeleteCriticalSection(&CriticalSection);

}

 

DWORD WINAPI ThreadProc( LPVOID lpParameter )

{

 

     SafeCriticalSection useCriticalSection(&CriticalSection);

 

    // 访问共享资源

     // ........

     ///////////

 

     return 0;

 

}

加入弹性设计的类SafeCriticalSection现在可以用来对所有的临界段进行漏掉LeaveCriticalSection的调用进行自动调用了.这下使用临界段编程的日子好过多了.
可是我们现在的模式下,类SafeCriticalSection和它所能管理的临界段分开在不同的地方.也就是说在使用临界段的时候我们的函数还要照应临界段变量的声明.要是能让我们的函数在想用临界段的时候就使用一个int型的变量一样方便就好了.为了达到这个目的我们还需要进一步加强粒度控制.

安全方便的临界段类(进一步精化粒度控制)

为了达到象使用int型变量一样方便地使用临界段的效果,我们显然需要把临界段的声明,与控制操作封装在一个类里面.于是按照这个思路我们可以飞快的修改我们的SafeCriticalSectioin为如下的样子.
// 保证安全的使用方便的临界段的封装类

struct SafeCriticalSection

{

 

private:

     // 用一个嵌套类开封装临界段的进出操作

     struct op_enter_leave

     {

         op_enter_leave()

         {

              // 进入临界段

              EnterCriticalSection(inited_section());

         }

         ~op_enter_leave()

         {

              // 离开临界段

              LeaveCriticalSection(inited_section());

         }

 

     private:

 

         // 用一个嵌套类封装临界段的初始化和释放操作

         struct op_init_dele

         {

              op_init_dele()

              {

                   // 初始化临界段

                   InitializeCriticalSection(&m_section);

              }

              ~op_init_dele()

              {

                   // 释放临界段

                   DeleteCriticalSection(&m_section);

              }

              // 临界段变量的声明

              CRITICAL_SECTION m_section;

         };

 

         // 为临界段的进出操作提供一个操作对象

         static LPCRITICAL_SECTION inited_section()

         {

              static op_init_dele inied; // 注意这个静态变量的定义. 它保证了临界段只被初始化一次.

              return &inied.m_section;

         }

        

     };

 

 

     //  这个成员变量的构造和少数析构函数会保证进入临界段和离开临界段的有序操作.

     op_enter_leave m_op;

};
 

现在我们可以和使用int型的变量一样方便地使用临界段了.当需要临界段的时候,只需要象下面的一行代码就可以了.
 

SafeCriticalSection useCriticalSection;
 

是不是和使用int型的变量一样方便呀? 可是我们这个模式下又有了一个新问题,我们的封装类总是使用一个临界段. 要是我们要使用多个临界段以保护不同的临界资源,我们的类SafeCriticalSection就无能为力了.呵呵,经过进一步的粒度封装后弹性没有了.

安全方便且有弹性的临界段类(进一步精化弹性)

为了能够让我们的安全方便的临界段封装类能够满足使用多个临界资源的要求,需要为我们的类SafeCriticalSection再加上一些粒度控制.于是我们进一步改造SafeCriticalSection类. 加入弹性控制的SafeCriticalSection类如下:
 

// 保证安全的使用方便的 富有弹性的临界段的封装类

template <class T>

struct SafeCriticalSection

{

     // 内容同上

};

 

现在我们为我们的不同的共享资源使用不同的临界段来进行保护了.使用的时候大致的代码如下:
 

     class ShareResource{};

     SafeCriticalSection<ShareResource> useCriticalSection;

 

现在,只要有一种共享资源,就可用一行代码就完成对这个资源的访问保护了.最妙的是,这个要保护的资源的名称就在这一行代码里.
 

看看我们进行粒度和弹性控制的过程(小小总结一下)

通过上面的对临界段的封装,我们可以看出要进行粒度和弹性控制,是一个不断提升使用方便度的过程.这个过程中通常伴随一个封装程序不断紧凑的过程.在加强封装程度的过程中会出现弹性下降的情况.当出现弹性下降的情况时我们需要把要提升弹性的地方进行参数化.
 

看看SafeCriticalSection具体做了些什么(小小升华一下)

让我们来看看SafeCriticalSection这个类具体做了些什么. 首先它会在你需要的时候(即你想要对共享资源进行保护时)会为你构建一个临界段, 并保证你在使用共享资源时,按正确的时序调用进入和离开临界段的函数. 当你不要需要这时候(程序退出时)这个类还会自动地为你释放它所构建的临界段.
分析这个过程我们发现它有三个自动比较有趣.一个是自动分配和释放临界段,一个是自动进入和退出临界段,一个是自动为所需要保护的共享资源分配相应的临界段.
现在我们可以想到与”临界段”这样的使用模式相仿的还有很多,比如互斥量,共享内存等.显然我们的有关互临界段的粒度和弹性控制模式,稍加修改就可以用来进行对互斥量,共享内存的粒度和弹性控制.
如果我们把临界段,互斥量,共享内存这些统统看成一种资源.呵呵,我们找到了一个按需分配的释放资源,并保证以正确的顺序访问资源的模式.
我们可以把这一模式进行封装,并一步参数化这个更高级的封装,而使它成为一个小小的库.
那么,该怎么封装并参数化呢?
什么?这还有疑问吗? 请看文章的上面几个部分.