|
|
今天遇到一个关于COM的问题，于是找到这篇文章，相信许多对COM不怎么熟悉的人来说应该有益的：原文引自：http://www.microsoft.com/china/MSDN/library/windev/COMponentdev/CDwickedtoc.mspx?mfr=true
超酷代码：来自 COM 经验的八个教训
发布日期： 5/20/2004 | 更新日期： 5/20/2004
Jeff Prosise（Jeff Prosise 是 Programming Windows with MFC（Microsoft Press，1999 年）一书的作者。他还是 Wintellect（一家软件咨询和教育公司）的创办人之一，该公司的网址是 http://www.wintellect.com。）
在日常工作中，我看到过许多由不同开发人员编写的 COM 代码。我为许多富于创造性的使用 COM 的工作方式感到惊讶，有一些使 COM 工作的巧妙代码可能连 Microsoft 都没有想到。同样，看到一些错误一次又一次地重犯，使我免不了心灰意懒。这些错误很多都与线程和安全有关，完全不成比例，而这也正是 COM 文档资料中最缺少的两个领域。如果不仔细计划，它们也是最可能遇到的并可能会绊住您的两个领域。
本月的“超酷代码”专栏与以前的大多数专栏有所不同。它并未提供一段可在您自己的应用程序中使用的超酷代码。相反，它将讲述实现基于 COM 的应用程序的正确方式和错误方式。它将讲述一些来自艰难实践的教训，以及如何避免落入已经让许多 COM 开发人员吃尽苦头的陷阱。
在下面的篇幅中，您将读到八位程序员的记述，这些教训都来自他们的痛苦经历。每个故事都是真实的，但为了保护无辜者，名字都已隐去。我的目的是，通过这些真实的 COM 故事，使您不再重蹈其他 COM 程序员的覆辙。它们还可能会帮助您在编写的代码中找出存在潜在问题的地方。无论情况如何，我想您都会获得愉快的阅读体验。
本页内容
总是调用 CoInitialize(Ex)
不要在线程之间传递原始接口指针
STA 线程需要消息循环
单元模型对象必须保护共享数据
谨慎启动用户
DCOM 不适于防火墙
使用线程或异步调用来避免 DCOM 超时设定太长
共享对象并不容易
与我联系
总是调用 CoInitialize(Ex)
几个月前，我收到了一封朋友的电子邮件，他就职于一家著名的硬件公司。他的公司编写了一个非常复杂的基于 COM 的应用程序，其中使用了许多进程内和本地（进程外）的 COM 组件。在开始时，应用程序创建了 COM 对象以服务于运行在多线程单元 (MTA) 中的各种客户端线程。该对象还可以托管给 MTA，这意味着接口指针可以在客户端线程之间自由交换。在测试中，我的朋友发现在应用程序准备关闭之前，一切都进行得不错。然后，不知是什么原因，对 Release 的调用（必须执行此调用，以便正确释放客户端占用的接口指针）被锁定了。他的问题是：“到底是哪里出了问题？”
其实答案非常简单。应用程序的开发人员其他都做得很对，只有一点例外，而这点又非常重要：他们没有在所有的客户端线程中调用 CoInitialize 或 CoInitializeEx。现代 COM 的基本原则之一，就是每个使用 COM 的线程都应该先调用 CoInitialize 或 CoInitializeEx 来初始化 COM。这条原则是无法免除的。除了其他事情以外，CoInitialize(Ex) 应将线程放入单元中，并初始化重要的每线程状态信息（这对于 COM 的正确操作是必需的）。调用 CoInitialize(Ex) 失败通常会在应用程序生命期早期以失败的 COM API 函数的形式表现出来，最常见的是激活请求。但有时问题很隐蔽，直到一切都太晚了（例如对 Release 的调用一去不复返了）才表现出来。当开发小组将 CoInitialize(Ex) 调用添加到所有接触 COM 的线程之后，他们的问题就迎刃而解了。
具有讽刺意义的是，Microsoft 竟是 COM 程序员有时不调用 CoInitialize(Ex) 的原因之一。Microsoft 知识库中包含的一些文档中说，调用 CoInitialize(Ex) 对基于 MTA 的线程来说不是必需的（有关示例，请参阅文章 Q150777）。是的，在很多情况下，我们可以跳过 CoInitialize(Ex) 而不会出现问题。但是，这样是不应该的，除非您知道自己在干什么，并且可以绝对肯定自己不会受到负面影响。调用 CoInitialize(Ex) 是没有害处的，因此我建议 COM 程序员始终从某个与 COM 相关的线程中调用它。
返回页首
不要在线程之间传递原始接口指针
我咨询的首批 COM 项目之一就涉及到一个包含 100,000 行代码的分布式应用程序，该程序是由美国西海岸的一个大型软件公司编写的。该应用程序在多个机器上创建了数十个 COM 对象，并从客户端进程启动的背景线程中调用这些对象。开发小组遇到问题了，调用要么消失得无影无踪，要么在没有明显原因的情况下失败。他们给我演示的最惊人的症状是：当一个调用无法返回时，在同一台机器上启动其他支持 COM 的应用程序（包括 Microsoft Paint 等）会频繁导致这些应用程序被锁定。
检查他们的代码后发现，他们违反了 COM 并发的一个基本规则，就是说，如果一个线程要与另一个线程共享一个接口指针，它应首先封送该接口指针。如果有必要，封送接口指针可使 COM 创建一个新的代理（以及一个新的信道对象，将代理和存根结对），以允许从另一个单元向外调用。不通过封送而将原始接口指针（内存中的一个 32 位地址）传递给另一个线程，会绕过 COM 的并发机制，并且如果发送和接收的线程位于不同的单元中，将出现各种不良行为。（在 Windows 2000 中，由于两个对象可以共享一个单元，但又位于不同的上下文中，因此如果线程位于同一个单元中，可能会使您陷入困境。）典型的症状包括调用失败和返回 RPC_E_WRONG_THREAD_ERROR。
Windows NT 4.0 和更高版本可以使用一对名为 CoMarshalInterThreadInterfaceInStream 和 CoGetInterfaceAndReleaseStream 的 API 函数，在线程之间轻松地封送接口指针。假定您应用程序中的一个线程（线程 A）创建了一个 COM 对象，继而接收了一个 IFoo 接口指针，并且同一进程中的另一个线程（线程 B）想调用这个对象。在准备将接口指针传递给线程 B 时，线程 A 应该封送该接口指针，如下所示：
CoMarshalInterThreadInterfaceInStream (IID_IFoo, pFoo, &pStream);
在 CoMarshalInterThreadInterfaceInStream 返回后，线程 B 就可以安全地取消封送该接口指针：
IFoo* pFoo;
CoGetInterfaceAndReleaseStream (pStream, IID_IFoo, (void**) &pFoo);
在这些示例中，pFoo 是一个 IFoo 接口指针，pStream 是一个 IStream 接口指针。COM 在调用 CoMarshalInterThreadInterfaceInStream 时初始化 IStream 接口指针，然后在 CoGetInterfaceAndReleaseStream 内部使用和释放该接口指针。实际上，您通常要使用一个事件或其他同步化基元来协调这两个线程的行为 — 例如，让线程 B 知道接口指针已准备好，可以取消封送。
请注意，以这种方式封送接口指针不会出现任何问题，因为 COM 有足够的智能，在不需要进行封送时不会去封送（或重新封送）指针。如果在线程之间传递接口指针时这样做，使用 COM 就轻松多了。
如果调用 CoMarshalInterThreadInterfaceInStream 和 CoGetInterfaceAndReleaseStream 看起来太麻烦，您还可以通过将接口指针放在全局接口表 (GIT) 中，并让其他线程去那里检索它们，从而实现在线程之间传递接口指针。从 GIT 中检索到的接口指针在被检索时会自动封送。更多信息，请参阅 IGlobalInterfaceTable 中的文档。请注意，GIT 只存在于 Windows NT 4.0 Service Pack 4 及更高版本中。
返回页首
STA 线程需要消息循环
上一部分中描述的应用程序还有另一个致命缺陷。看看您是否能指出来。
这个特殊的应用程序恰好是用 MFC 编写的。在一开始，它使用了 MFC 的 AfxBeginThread 函数启动一系列辅助线程。每个辅助线程要么调用 CoInitialize 要么调用 AfxOleInit（MFC 中类似 CoInitialize 的函数）来初始化 COM。某些辅助线程则调用 CoCreateInstance 来创建 COM 对象，并将所返回的接口指针封送到其他辅助线程。从创建这些对象的线程中调用对象将非常顺利，但从其他线程的调用却从不返回。您知道这是为什么吗？
如果您认为问题与消息循环（或缺少消息循环）相关，那么答案完全正确。事实确实如此。当一个线程调用 CoInitialize 或 AfxOleInit 时，它是放在单线程单元 (STA) 中。当 COM 创建一个 STA 时，它会创建一个随附的隐藏窗口。以 STA 中的对象为目标的方法调用将转换为消息，并放入与该 STA 关联的窗口的消息队列中。当运行在该 STA 中的线程检索到代表方法调用的消息时，隐藏窗口的窗口过程就会将消息转换回方法调用。COM 使用 STA 执行调用序列化。STA 中的对象一次不可能接收一个以上的调用，因为每个调用都要传递给一个而且是惟一一个运行在对象单元中的线程。
如果基于 STA 的线程无法处理消息会怎么样呢？如果它没有消息循环又会怎么样呢？针对该 STA 中对象的单元间方法调用将不再返回；它们将在消息队列中被永远搁置。MFC 辅助线程中没有消息循环，因此如果寄宿在这些 STA 中的对象要从其他单元的客户端接收方法调用，那么 MFC 辅助线程和 STA 是配合不好的。
这个故事的寓意何在呢？STA 线程需要消息循环，除非您肯定它们不会包含要从其他线程调用的对象。消息循环可以像这样简单：
MSG msg;
while (GetMessage (&msg, 0, 0, 0))
DispatchMessage (&msg);
另一种方案是将 COM 线程移到 MTA 中（或者在 Windows 2000 中，移到中立线程单元，即 NTA 中），这里没有消息队列依赖项。
返回页首
单元模型对象必须保护共享数据
另一个困扰 COM 开发人员的通病是标记为 ThreadingModel=Apartment 的进程内对象。这项指定告诉 COM，对象的实例必须只能在 STA 中创建。它还可让 COM 自由地将这些对象实例放在任何主机进程的 STA 中。
假设客户端应用程序有五个 STA 线程，每个线程都使用 CoCreateInstance 来创建同一个对象的一个实例。如果线程是基于 STA 的，且对象标记为 ThreadingModel=Apartment，则这五个对象实例将在对象创建者的 STA 中创建。因为每个对象实例都在占用其 STA 的线程上运行，因此所有五个对象实例都可以并行运行。
到目前为止，一切良好。现在考虑一下，如果这些对象实例共享数据会发生什么情况。因为对象都在并发线程上执行，两个或更多的对象可能会同时尝试访问同一个数据。除非所有这些访问都是读取访问，否则就会酿成灾难。问题可能不会很快显现出来；它们会以和时间紧密相关的错误形式出现，因此很难诊断和重现。这就解释了以下事实的原因：ThreadingModel=Apartment 对象应该包括可同步对共享数据的访问的代码，除非您能够确定对象的客户端不会对执行访问的方法进行重叠调用。
问题在于，太多的 COM 开发人员相信 ThreadingModel=Apartment 能够使他们免于编写线程安全的代码。事实并非如此 — 至少不完全如此。ThreadingModel=Apartment 并不意味着对象必须是完全线程安全的，它代表的是一个对 COM 的承诺，即访问两个或更多对象实例共享的数据（或此对象和其他对象的实例共享的数据）时是以线程安全的方式进行的。而提供该线程安全性的任务应该由您，即对象实现者来负责。共享数据的类型和大小多种多样，但大多是以全局变量、C++ 类中的静态成员变量和函数中声明的静态变量的形式出现。即使是以下这样无害的语句也会在 STA 中出问题：
static int nCallCount = 0;
nCallCount++;
因为这个对象的所有实例都将共享一个 nCallCount 实例，编写这些语句的正确方式如下：
static int nCallCount = 0;
InterlockIncrement (&nCallCount);
注意：您可以使用临界区、互锁函数或您希望的任何方式，但不要忘了访问基于 STA 的对象共享的数据时要进行同步化！
返回页首
谨慎启动用户
这里还有一个问题让许多 COM 开发人员都吃过苦头。去年春天，有一家公司向我紧急呼救，他们的开发人员使用 COM 构建了一个分布式应用程序，其中客户端进程运行在与远程服务器的 Singleton 对象相连接的网络工作站上。在测试过程中，他们遇到了一些非常奇怪的行为。在一种测试场景中，客户端对 CoCreateInstanceEx 的调用可使它们与 Singleton 对象正常连接。而在另一个 |
|
IP卡
狗仔卡
发表于 2009-11-3 01:28:19
收藏
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡