超酷代码：来自 COM 经验的八个教训

原著：Jeff Prosise

本文转载自微软中国社区：http://www.microsoft.com/china/MSDN/library/windev/COMponentdev/CDwickedtoc.mspx

发布日期：5/20/2004
更新日期：5/20/2004

原文出处：Wicked Code: Eight Lessons from the COM School of Hard Knocks (Jeff Prosise)

　　在日常工作中，我看到过许多由不同开发人员编写的 COM 代码。我为许多富于创造性的使用 COM 的工作方式感到惊讶，有一些使 COM 工作的巧妙代码可能连 Microsoft 都没有想到。同样，看到一些错误一次又一次地重犯，使我免不了心灰意懒。这些错误很多都与线程和安全有关，完全不成比例，而这也正是 COM 文档资料中最缺少的两个领域。如果不仔细计划，它们也是最可能遇到的并可能会绊住您的两个领域。
　　本月的“超酷代码”专栏与以前的大多数专栏有所不同。它并未提供一段可在您自己的应用程序中使用的超酷代码。相反，它将讲述实现基于 COM 的应用程序的正确方式和错误方式。它将讲述一些来自艰难实践的教训，以及如何避免落入已经让许多 COM 开发人员吃尽苦头的陷阱。
　　在下面的篇幅中，您将读到八位程序员的记述，这些教训都来自他们的痛苦经历。每个故事都是真实的，但为了保护无辜者，名字都已隐去。我的目的是，通过这些真实的 COM 故事，使您不再重蹈其他 COM 程序员的覆辙。它们还可能会帮助您在编写的代码中找出存在潜在问题的地方。无论情况如何，我想您都会获得愉快的阅读体验。

总是调用 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);

IFoo* pFoo;
CoGetInterfaceAndReleaseStream (pStream, IID_IFoo, (void**) &pFoo);

MSG msg;
while (GetMessage (&msg, 0, 0, 0))
DispatchMessage (&msg);

static int nCallCount = 0;
nCallCount++;

static int nCallCount = 0;
InterlockIncrement (&nCallCount);

• 在服务器（在防火墙后寄存远程对象的机器）上，将 DCOM 配置为使用 TCP 作为其所选协议，如图 3 中所示。
• 在服务器上，限制 DCOM 将使用的端口范围。记住为每个服务器进程至少分配一个端口。图 4 中的示例将 DCOM 限制为端口 8,192 到 8,195。
• 打开您在步骤 2 中选择的端口，使 TCP 通信量能够通过防火墙。同时打开端口 135。

图 4 选择端口

　　执行这些步骤，DCOM 就可以很好地跨防火墙工作了。如果您愿意，SP4 和更高版本还可让您为单独的 COM 服务器指定终结点。更多信息，请阅读 Michael Nelson 关于 DCOM 和防火墙的优秀论文，该论文可在 MSDN Online 站点上找到（请参见 http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomfirewall.asp）。
　　还应注意的是，通过在服务器上安装 Internet 信息服务 (IIS)，并使用 COM Internet 服务 (CIS) 通过端口 80 路由 DCOM 通信量，SP4 和更高版本的用户还可以使用 CIS 来提供与防火墙兼容的 DCOM。有关该主题的更多信息，请参阅 http://msdn.microsoft.com/library/en-us/dndcom/html/cis.asp。

使用线程或异步调用来避免 DCOM 超时设定太长
　　总是有人问我当 DCOM 无法完成远程实例化请求或方法调用时出现的超时设定太长的问题。典型的场景如下：客户端调用 CoCreateInstanceEx 来实例化远程机器上的一个对象，但是这台机器临时离线了。在 Windows NT 4.0 上，激活请求不会立即失败，DCOM 可能会花上一分钟或更长时间来返回失败的 HRESULT。DCOM 还可能花费很长时间，使指向已不再存在或其主机已离线的远程对象的方法调用失败。如果可能，开发人员应该如何避免这些较长的超时设定呢？
　　要回答这个问题，几句话是讲不清楚的。DCOM 高度依赖于基础网络协议和 RPC 子系统。并没有什么神奇的设置可让您限制 DCOM 超时设定的持续时间。但是，我经常使用两种技巧来避免较长超时设定的负作用。
　　在 Windows 2000 中，当调用在 COM 信道中挂起时，您可以使用异步方法调用来释放调用线程。（有关异步方法调用的介绍，请参 MSDN Magazine 2000 年 4 月刊的“Windows 2000: Asynchronous Method Calls Eliminate the Wait for COM Clients and Servers Alike”。如果异步调用在合理时间内没有返回，您可以通过调用用于初始化调用的调用对象上的 ICancelMethodCalls::Cancel 来取消它。
　　 Windows NT 4.0 不支持异步方法调用，甚至在 Windows 2000 中也不支持异步激活请求。怎么解决呢？从背景线程调用远程对象（或是实例化该对象的请求）。使主线程在事件对象上阻塞，并指定超时设定值以反映您愿意等待的时间长度。当调用返回时，让背景线程来设置事件。假设主线程使用 WaitForSingleObject 阻塞，当 WaitForSingleObject 返回时，返回值可以告诉您，返回是因为方法调用或激活请求返回，还是因为您在 WaitForSingleObject 调用中指定的超时设定到期。您不能在 Windows NT 4.0 中取消挂起调用，但是至少主线程可以自由地执行自己的任务。
　　下面的代码演示了基于 Windows NT 4.0 的客户端如何才能从背景线程调用对象。

//////////////////////////////////////////////////////
// Placing a Method Call from a Background Thread 
/////////////////////////////////////////////////////　
HANDLE g_hEvent;
IStream* g_pStream;

// Thread A
g_hEvent = CreateEvent (NULL, FALSE, FALSE, NULL);
CoMarshalInterThreadInterfaceInStream (IID_IFoo, pFoo, &g_pStream);
DWORD dwThreadID;
CreateThread (NULL, 0, ThreadFunc, NULL, 0, &dwThreadID);
DWORD dw = WaitForSingleObject (g_hEvent, 5000);
if (dw == WAIT_TIMEOUT) {
    // Call timed out
}
else {
    // Call completed
}
...

// Thread B
IFoo* pFoo;
CoGetInterfaceAndReleaseStream (g_pStream, IID_IFoo, (void**) &pFoo);
pFoo->Bar (); // Make the call!
SetEvent (g_hEvent);
CloseHandle (g_hEvent);