COM的多线程模型

http://blog.csdn.net/phil2036/article/details/3852949

       COM的多线程模型是COM技术里头最难以理解的部分之一，很多书都有涉及但是都没有很好的讲清楚。很多新人都会在这里觉得很迷惑，google大神能搜到一篇vckbase上的文章，但是个人建议还是不要看的好几乎是胡说八道在乱搞。

      COM自己其实并没有任何多线程模型，所以他用的多线程模型还是WIN32里头的那一套线程和同步对象。作为准备，这里先简单讲一下WIN32的线程和同步。作为惯例一讲WIN32的线程和同步对象就要把进程、线程这两个东西讲一遍，但是这里不讲，因为会看COM的对这部分已经很熟悉了，如果不熟悉的话建议也不要看COM了先回头看看《Windows核心编程》和《Windows高级编程》。WIN32的线程可以分为两种，UI线程和工作线程。UI线程是一种与一个窗口绑定的线程，其特点是包含一个窗口一个消息循环和一个窗口过程，由于消息循环的存在导致了其天生就具有一种同步机制：任何发送到该线程的消息都会被消息循环同步，不会有任何两个或以上的消息同时被窗口过程处理，所有消息都会被消息循环串行化；工作线程则可以认为是一个函数在一个线程上的一次运行，这种线程不具备任何自带的同步机制，如果要对两个工作者线程实施某种同步则只能使用WIN32的同步对象如CriticalSection或者Event等等。

      接下来看COM的多线程模型，从VS2005的ATL工程向导上可以看到COM多线程模型分为这么几类：单线程(Single)、套间(Apartment)、两者(Both)、自由(Free)。这个部分个人觉得翻译不是很好，单线程(Single)个人认为翻译成单套间会比较好，原因后面有具体描述，但是作为尊重MS向导或者不至于更加把这部分弄得混乱，下面的术语还是引用MS向导上的讲法并且我尽可能使用英文术语。

      可以看到COM多线程模型里最多用到的两个字是套间，那么先解释一下套间。套间可以根据他的英文想象一个房间，这个房间周围有墙，所以要进到这个房间必须用一种手段来穿透（通过门或者类似的东西），而这个房间里放的就是一个或者多个COM对象。对套间更理论性的解释是，在一个套间内存在一个或多个COM组件，而套间之间存在有一个明确的界限，并且套间内只存在唯一的一个套间线程，这个套间线程存在一个类似于消息循环（其实不应该用类似的，他就是一个隐藏了窗口的消息循环）来保证其天生所具有的同步性。看了这个定义你会觉得套间像什么？没错，一个只有一个主线程的Windows窗口应用程序进程。所以套间就是一个UI线程！做为UI线程他自然就能完成同步的功能。接下去分几个部分来讲这几种COM线程模型。

 

一、单线程(Single)

      前面讲过这个模型最好是被翻译成单套间的好，因为这种多线程模型并不是说COM组件只能被用在单线程程序里头的，相反组件还是可以被正常的用在多线程程序里的。这种模型的真实意义是即使你的程序是多线程的并且在每个线程里都调用了CoInitalize(0,COINIT_APARTMENT)，事实上在你的程序进程里头也只创建一个套间，并且把所有的组件都放到这个套间里头并由这个套间所拥有的消息循环来保证同步性。

      或许这样讲不全面，但是上面一段确实讲了一种最简单的情况，就是所有的组件都按Single模型来创建。如果不是这样会什么情况呢，举个例子说A、B、C三个组件按Single模型创建，D按Apartment模型创建，并且四个组件分别在TA、TB、TC、TD四个线程里创建实例（每个线程都调用CoInitalize(0,COINIT_APARTMENT)来创建环境），那么组件A、B、C运行在由TA创建的套间里（TB、TC都没有创建套间，TA是这个套间的套间线程），而组件D则独立运行在TD创建的套间里（TD是这个套间的套间线程），这里一共就有了两个套间。这样应该是完整的情况了，再复杂的情况我想你都能推出来了。

二、套间(Apartment)

      这种模型与前一种模型很相似，可以都被认为是创建WIN32概念上的UI线程，但是不同的在于，Single模型无论你在多少个线程里调用多少次CoInitalize(0,COINIT_APARTMENT)都只创建一个套间，套间的套间线程是你第一次调用CoInitalize(0,COINIT_APARTMENT)的线程，而Apartment模型则是你在一个线程上调用一个CoInitalize(0,COINIT_APARTMENT)就创建一个套间，并且把这个线程作为套间线程。

三、自由(Free)

      这种模型就是工作者线程了，COM不再用消息循环来提供同步机制了。你要在多线程里使用，OK，那你自己给他做同步机制（或者由组件开发者把组件做成线程安全的）。你要单线程里使用，那更好无论如何都不需要同步了。

四、两者(Both)

      这种模型保证了组件即能在套间模型使用也能在自由模型使用。例如说组件自身被创建为Apartment或者Single，但是使用者用CoInitalize(0,COINIT_MULITITHREAD)来创建环境，那么COM自己会再创建一个线程用CoInitalize(0,COINIT_APARTMENT)来创建环境供组件运行，反之亦然。

 

      最后讲一下跨套间调用的问题，从上面的描述可以看到在Single和Apartment这两种模型里头套间内调用或者通过COM机制套间之间的通信都会被同步化，但是如何跨套间调用呢，比如说我们经常做这种事情，把一个存在在套间内组件的接口指针作为线程参数传递到另外一个线程中使用，或者两个组件存在于不同的套间中，但是由于连接点或者回调的原因需要互相调用。这个时候我们就需要使用proxy/stub机制，在传递接口指针之前调用CoMashalInterThreadInterface这个函数（我估计这个是所有WIN32API里函数名最长的函数了，MS真不让人过好日子-.-|||）来包装接口指针给PS dll来传递，然后再那个调用的线程或者套间里使用CoGetInterfaceAndReleaseStream来重新获得被调度过的接口指针，这样就能确保COM的线程同步机制能够正常的运行。

 

      好了，全部讲完了，如果还不清楚建议去看一下《COM技术内幕》里的第十二章，这本书是我见过的所有书里对这部分描述得最好的一本（胜过《ATL技术内幕》），特别是里面那几张图，对理解这些模型非常有帮助，这书网上有电子版。

COM多线程原理与应用

前言：

COM多线程一直是个不容易弄清的问题，我也被困扰了很久，特别是COM在线程方面的术语总是不能统一。本文是为了将我所学所用得做一个总结，本文不保证一定正确，但是会随着时间的推移逐渐完善改正。

 

套间：

套间的定义：

       我个人认为<<COM技术内幕>>中关于套间的定义是错误的，应采用<<COM本质论>>中的定义。

<<COM技术内幕>>中-----

套间（Apartment），一个由用户界面线程（套间线程）和一个消息循环构成的概念性实体。

<<COM本质论>>中------

套间定义了一组对象的逻辑组合，这些对象共享同一组并发性和重入限制。一个线程要想使用COM，必须先进入一个套间。COM规定，只有运行在对象套间中的线程才能访问该对象。

套间的分类：

COM定义了两种类型的套间，STA（单线程套间）和MTA（多线程套间）。

STA的特点是套间内永远只有一个线程运行，并且一定是创建该套间的初始线程。因而开发只运行在STA中的组件不需要考虑线程同步等问题。

STA中包含了一个不可见的窗口，所以透过窗口的消息循环机制对消息队列的处理，保证了同一时刻只有一个调用请求被执行，这就是组件不需要处理同步的原因。

 

MTA的特点是套间内可以有多个线程运行，并且还可以创建新的线程。在MTA中运行的组件必须自己实现线程的同步。

 

 

套间的进入和退出：

线程通过CoInitializeEx函数进入套间，该函数的第二个参数通过传递COINIT_APARTMENTTHREADED和COINIT_MULTITHREADED标志了套间类型。如果传递COINIT_APARTMENTTHREADED，该线程将创建自己私有的套间，别人不能进入。如果传递COINIT_MULTITHREADED，该线程将进入当前进程范围内的MTA。

线程调用CoUninitialize函数用于退出所在的套间。只有退出后才可以进入其它类型的套间。

 

对象的同步：

组件对象的同步：

根据是否支持多线程同步，组件对象可以分为单线程对象和多线程对象。

COM对象线程模型：

每个COM对象都可以决定自己将运行在什么样的套间内，这称为COM对象的线程模型。

组件将运行在什么样的套间里面，这是由组件开发者决定的，调用组件的客户程序不需要关心。但是如果调用线程所在的套间和组件运行的套间不是同一套间，COM将插入代理/存根机制，调用线程在自身的套间内调用代理上的方法使用对象方法，而对象将运行在它需要的套间内。

进程内对象线程模型的种类：

线程模型的种类取决于注册表中ThreadingModel的值----------

1）  Both 表示组件可以运行在STA和MTA中

2）  Free 表示组件只能运行在MTA中

3）  Apartment表示组件只能运行在STA中

4）  为空表示组件只能运行在进程第一个创建的STA（主STA中）中。

如果调用线程的套间能够满足进程内组件的线程模型的要求，则直接创建组件对象，并不需要代理。

如果调用线程的套间不能满足进程内组件的线程模型的要求，则COM会在另一个合适的套间内（如果没有合适的套间，COM会创建一个）创建对象，然后给调用线程返回代理。

如果组件和客户程序不在同一个进程或者不在同一台机器，那必然是在两个套间中，COM会创建代理/存根。

如果组件对象的线程模型是Both或者Free，组件必须是多线程对象。

如果组件对象的线程模型是空，则组件可以是单线程对象或者多线程对象。这时候多线程对象内部的同步机制其实没有意义，因为不会有多个线程同时访问对象。

如果组件对象的线程模型是Apartment，情况将分两种：

a)       组件内部没有全局变量和静态变量，组件可以是单线程对象

b)      组件内部有全局变量和静态变量，组件应该是多线程对象，并对全局变量和静态变量进

行访问保护。

 

ATL对多线程的支持：

ATL中对COM对象中同步的支持有自己的考虑：如果COM对象本身就是不考虑同步的单线程对象，ATL就不应该对该对象的任何数据成员包括对象引用变量m_cRef进行同步保护。因为同步保护是需要额外的耗费资源的。ATL中的原则是只在应该需要保护的场合进行同步保护。这样做是符合ATL的设计目的----一切为了效率。

对象引用的保护：

CComSingleThreadModel、CComMultiThreadModel、CComMultiThreadModelNoCS类里面都定义了静态成员函数Increment和Decrement。CComObjectRootEx类的模板参数接受以上三个类并使用他们的静态成员函数，而我们的组件实现类从CComObjectRootEx类派生，从而获得了根据我们组件是否支持多线程而对对象引用进行同步的功能。一句话，我们只要派生具有合适的模板参数的CComObjectRootEx类就可以了。如下面我们的类：

class ATL_NO_VTABLE CMIS :

     public CComObjectRootEx<CComSingleThreadModel>,

CMIS类不需要考虑对象引用的同步保护，因为我们的组件对象是单线程对象，线程模型为空或者为Apartment。

       但是请注意ATL工程的组件类脚本中默认线程模型是both，这就会带来问题，所以我们手动修改它。

       如果我们改动代码如下：

class ATL_NO_VTABLE CMIS :

     public CComObjectRootEx< CComMultiThreadModel >,那么我们的组件对象引用计数就受到同步保护，而且我们的组件对象自己负责同步保护。这样如果CMIS类里有成员变量，那么我们要对成员变量进行同步保护。

成员变量的保护：

       采用临界区方式进行同步保护我们要利用类CComMultiThreadModel。我们的组件实现类派生自CComObjectRootEx< CComMultiThreadModel >类。使用的方法极其简单，我们只要在需要防止多个线程同时执行的函数内部开始处加上如下代码：

       ObjectLock Lock(this);

     如果想使用多个临界区的话使用方法就没这么简单了，但是除非必须，否则我不建议这样做，因为很容易引起死锁。一定要用的话必须先阅读<<Windows核心编程>>和<<Win32多线程程序设计>>这两本书。

 

COM+导致的变化：

上下文概述：

COM+对于套间的概念进一步的扩展，要求每个对象都必须运行在上下文中。通过上下文来控制对象的线程同步。

套间被细分为一个或者若干个上下文。一个上下文只能在一个套间中。一个套间至少包含一个默认上下文。

位于同一个套间中的不同上下文之间的对象调用必须经过轻量级代理的列集。轻量级代理不同于套间之间的代理，因为性能损失较小。

 

一个没有被COM+托管的传统COM组件不使用轻量级代理。但是该COM组件将被认为是放到了它所生存的套间的默认上下文内部，该套件的其他上下文（如果有的话）访问默认上下文不需要轻量级代理，默认上下文的引入只是为了和COM+上下文的概念一致。

 

上下文对象：

       上下文对象具体代表了每个上下文。CoGetObjectContext用来获取当前对象所在的上下文对象。

       上下文对象暴露了IObjectContextInfo、IContextState、IObjectContext、IObjectContextActivity四个接口。后面两个接口是向后兼容MTS，可以忽略。

       IObjectContextInfo：：GetContextId方法可以获得上下文ID，调试时使用很方便。但是注意，只有COM组件被COM+管理后才能获得上下文对象，否则CoGetObjectContext将返回E_NOINTERFACE并返回NULL接口指针。所以如果我们开发的组件要同时适用于COM+和传统COM两种情况，就必须对CoGetObjectContext返回值进行查询并且作区分处理。

 

调用对象：

       当客户通过COM+服务调用COM对象时，COM+将创建名为“调用对象”的临时对象代表客户对COM对象的调用。调用对象将在方法返回后被销毁。

       调用对象暴露了两个与安全性设置相关的接口。

       CoGetCallContext函数可以让对象获取自己的调用对象，如果返回RPC_E_CALL_COMPLETE，则说明目前没有客户调用自己。