使DLL在系统中仅有一个实例

动态库是一种可执行文件，在操作系统支持下，它成为独立于进程的共享可执行文件。MSDN对动态库作如下概念定义：

动态链接库 (DLL) 是作为共享函数库的可执行文件。动态链接提供了一种方法，使进程可以调用不属于其可执行代码的函数。函数的可执行代码位于一个 DLL 中，该 DLL 包含一个或多个已被编译、链接并与使用它们的进程分开存储的函数。DLL 还有助于共享数据和资源。多个应用程序可同时访问内存中单个 DLL 副本的内容。

       可见，动态链接库的主要作用就是共享函数库。操作系统提供这样一种机制，保证函数库在系统中只有一份实例。至于DLL中的全局变量，对于每一个进程调用，操作系统会复制一份副本，以避免不同进程之间的干扰。

理论上讲，因为DLL的目的主要在于共享函数库，所提供的函数应尽量具有中立性，不应与应用细节关联太紧密。因为副本的增加要多占用系统资源与处理负担，所以，应该尽量避免在DLL中使用过多的全局变量，尤其是具有大量数据成员和成员函数的C++全局类对象。

       DLL是为面向模块和代码复用而设计，但它却时常被用来作软件之间的分层设计。用作分层设计目标的DLL，多进程复用没有太多的意义。实际应用当中也有一种情况，如果一个DLL操控制某个设备在系统中具有唯一性，我们必须要求该DLL考虑不能用于多个进程实例的特性。

       然而仅凭操作系统的一些基础性支持，就能做到实例唯一吗？非也，编程者要仔细理解DLL原理与机制，并作大量的练习处理后，才能做到真正的系统实例唯一。

方法之一：在DLL中定义全局变量

DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。我们可以这样设想，在DLL中定义一标志全局变量，每当进程调用之前，先检查此变量就可以得知是不是已有进程在调用DLL。

 

       然而，DLL中的全局变量会随新进程的应用而拷贝副本。你在A进程中看到的全局变量Flag_XX与你在B进程中看到的Flag_XX其实不是同一样标记。

 

       所以简单的定义全局变量作进程标记，是不能实现进程应用唯一性的判断。

方法二：定义共享数据段

       延续方法一的思路。如果能有一种机制，保证多个进程无论启动多少个DLL实例，全局变量不进行副本复制，这个问题就可以解决了。

 

       事实上，操作系统也确实有这个能力，编译器也为此类特殊应用作好的准备：

       #pragma data_seg("shared")

       BOOL G_bDllRunOnce=FALSE;

       #pragma data_seg()

       #pragma comment(linker, "/section:shared,rws")

      

采用以上代码段即可定义共享数据段，不论启动多少个调用DLL的进程，G_bDllRunOnce在系统中只有一个。在进程中，我们一般不要做引用DLL中的全局变量。如果引用，会造成应用代码与DLL之过份的耦合关系统。一般的做法是设定一个接口函数，或者在初始化函数中，通过对共享段该变量的判断，来为调用指示DLL实例状态。

 

       WJPROTOCOL_API INT InitWJUsb(INT nTimeout,HWND hWnd)

{

//#if INSTANCE_SHARE_MODE ==   ONLY_ONE_INSTANCE

              if (G_bDllRunOnce==TRUE) return FALSE;

//#endif

              ……

}

 

这样做，确定能达到此目的。

       然而真的吗？就凭共享数据段定义就能解决吗？现实当中恐怕没有这么简单的事吧！只到有一天，当一份调用DLL的进程实例正运行时，另一个DLL实例文件存放在应用程序的调试目录中，结果在VC的F5下，InitWJUsb的代码被执行到“if (G_bDllRunOnce==TRUE) return FALSE;”没有预期return，而是跳到了该行之后。WHY？

 

       后来，经观察得知，如果操作系统中只有一份DLL程序文件，共享数据段就能正确指示DLL唯一性。否则的话，系统唯一性就不存在。

方法三：使用命名内核对象

       以下是内核对象的概念，摘自《WINDOWS核心编程》。

       ============================================

统要创建和操作若干类型的内核对象，比如存取符号对象、 事件对象、文件对象、文件映射对象、I / O 完成端口对象、作业对象、信箱对象、互斥对象、管道对象、进程对象、信标对象、线程对象和等待计 时器对象等。这些对象都是通过调用函数来创建的。

 

例如，C r e a t e F i l e M a p p i n g 函数可使系统能够创建一个文件映射对象。每个内 核对象只是内核分配的一个内存块，并且只能由该内核访问。该内存块是一种数据结构，它的成员负责维护该对象的各种信息。有些数据成员（如安全性描述符、使用计数等）在所有对象类型中是相同的，但大多数数据成员属于特定的对象类型。例如，进程对象有一个进程I D 、一个基 本优先级和一个退出代码，而文件对象则拥有一个字节位移、一个共享模式和一个打开模式。

 

       由于内核对象的数据结构只能被内核访问，因此应用程序无法在内存中找到这些数据结构并直接改变它们的内容。M i c r o s o f t 规定了这个限 制条件，目的是为了确保内核对象结构保持状态的一致。这个限制也使M i c r o s o f t 能够在不破坏任何应用程序的情况下在这些结构中添加、 删除和修改数据成员。

 

如果我们不能直接改变这些数据结构，那么我们的应用程序如何才能操作这些内核对象呢？解决办法是，Wi n d o w s 提供了一组函数，以便用定 义得很好的方法来对这些结构进行操作。这些内核对象始终都可以通过这些函数进行访问。当调用一个用于创建内核对象的函数时，该函数就返回一 个用于标识该对象的句柄。该句柄可以被视为一个不透明值，你的进程中的任何线程都可以使用这个值。将这个句柄传递给Wi n d o w s 的各个函 数，这样，系统就能知道你想操作哪个内核对象。

 

为了使操作系统变得更加健壮，这些句柄值是与进程密切相关的。因此，如果将该句柄值传递给另一个进程中的一个线程（使用某种形式的进程间的 通信）那么这另一个进程使用你的进程的句柄值所作的调用就会失败。

 

       然而也有一些机使内核对象能够跨越进程边界。为内核对象命名是一种方法，许多（虽然不是全部）内核对象都是可以命名的。例如，下面的所有函数都可以创建命名的内核对象： HANDLE CreateMutex、HANDLE CreateEvent、HANDLE CreateSemaphore、HANDLE CreateWaitableTimer、HANDLE CreateWaitableTimer、HANDLE CreateFileMapping、HANDLE CreateJobObject等。

 

所有这些函数都有一个共同的最后参数p s z N a m e 。当为该参数传递N U L L 时，就向系统指明了想创建一个未命名的（匿名）内核对象。未命名的内核对象并不真真是没有名称，而是由操作系统替你代办，生成了一个你不知道的名字。

       ============================================

 

内 核对象在系统内是唯一的，唯一性由操作系统保证。你若创建一个未命名对象的话，操作系统会为你考虑这一点，选取一个当前系统中没使用的唯一名字。如果创建 了一个命名对象，而后再创建与此同名的内核对象的话，可想而知，肯定会引起返回对象已存在的错误。当然，创建动作被转为打开动作，内核对象的计数器由此而 增加。

HANDLE hMutex = CreateMutex(&sa, FALSE, "JeffObj");
   
   

if (GetLastError() == ERROR_ALREADY_EXISTS)
   
   

{
   
   

   //Opened a handle to an existing object.
   
   

   //sa.lpSecurityDescriptor and the second parameter
   
   

   //(FALSE) are ignored
   
   

}
   
   

else
   
   

{
   
   

   //Created a brand new object.
   
   

   //sa.lpSecurityDescriptor and the second parameter
   
   

   //(FALSE) are used to construct the object.
   
   

}
   
   

 

如果我们在DLL中创建一全局命名内核对象，通过对其存在性判断，就可以做到这一点，而不管该DLL程序文件在系统中的分布。

 

G_hEvtStopWatch = CreateEvent(NULL,TRUE,FALSE,"EvtUsbThreadWatch");

if (GetLastError() == ERROR_ALREADY_EXISTS)

{

       return FALSE;

}

 

       然而这样做有一种非常严重的隐患。如果另一个程序创建名为“EvtUsbThreadWatch”事件对象，而没有很好的判断唯一性的话，两个程序共用一个“EvtUsbThreadWatch”事件对象，这将引起极其严重的后果。

 

       虽然这种事情发生的机率很低，然而确实存在这种可能性。      

方法四：使用以GUID字符串命名的内核对象

       如果我们彼此能创建一种根本不可能，或者是可能性极低的命名方案的话，就可以解决这个问题。

       全局唯一标识符GUID可以很好的解决这个问题。

      

G_hEvtStopWatch = CreateEvent(NULL,TRUE,FALSE,

"{FA531CC1-0497-11d3-A180-00105A276C3E}");

if (GetLastError() == ERROR_ALREADY_EXISTS)

{

       return FALSE;

}

 

       如你所看到的，GUID作为内核对象的名称，确实太“肥胖”，会多占用系统资源。另外，不能见名知义，代码阅读困难，维护起来不方便。

       对于前一个问题，我们实在没有办法，GUID不是凭空想出来的，没有足够长的字符系列，根本无法保证名称重复的最小概率。至于后面的缺点，可以用一个宏定义来解决，采用如下的方式：

 

       #define   EvtUsbThreadWatch     "{FA531CC1-0497-11d3-A180-00105A276C3E}"

G_hEvtStopWatch = CreateEvent(NULL,TRUE,FALSE, EvtUsbThreadWatch);

if (GetLastError() == ERROR_ALREADY_EXISTS)

{

       return FALSE;

}

 

至此，问题解决。