超酷代码：来自 COM 经验的八个教训
| 原著：Jeff Prosise
总是调用 CoInitialize(Ex) 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 对象正常连接。而在另一个场景中，对 CoCreateInstanceEx 的相同调用产生了多个对象实例和多个服务器进程，使客户端无法与同一个对象 实例连接，从而实际影响了应用程序。在这两个场景中，硬件和软件是完全相同的。 此问题似乎与安全有关。当处理远程激活请求的 COM 服务控制管理器 (SCM) 在另一台机器上启动一个进程时，它会为该进程分配一个标识。除非另外指定，它选择的标识就是启动用户的标识。换句话说，分配给服务器进程的标识与启动它的客户端进程的标识相同。在这种情况下，如果 Bob 登录机器 A，并使用 CoCreateInstanceEx 连接机器 B 上的 Singleton 对象，而 Alice 也在机器 C 上如法炮制，就会启动两个不同的服务器进程（至少在两台不同的 WinStation 上），实际上使客户端无法再用 Singleton 语义与共享的对象实例连接。 两个测试场景之所以会产生大相径庭的结果，其原因就是在一个场景（那个可以工作的场景）中，所有测试人员都使用只为测试而设置的一个特殊帐户以同一个人的身份登录。而在另一个场景中，测试人员都使用他们的普通用户帐户登录。当两个或更多的客户端进程具有相同标识时，它们可以成功连接到配置为假定启动用户标识的服务器进程。但是，如果客户端有不同的标识，SCM 会使用多个服务器进程（每个唯一客户端标识一个）分隔分配给不同对象实例的标识。 图 1 DCOMCNFG 中的用户帐户 找到问题以后，解决起来就很简单了：配置 COM 服务器，让其使用特定的用户帐户而不是假定启动用户的标识。完成这一任务的一种方式是在服务器机器上运行 DCOMCNFG（Microsoft 的 DCOM 配置工具），并将“launching user ”更改为“This user”（请参见图 1）。如果您喜欢通过编程方式进行更改（可能从安装程序着手），请在主机注册表的 HKEY_CLASSES_ROOT\AppID 部分的 COM 服务器项中添加 RunAs 值（请参见图 2）。 图 2 添加 RunAs 值到注册表中 您还需要使用 LsaStorePrivateData 将 RunAs 帐户的密码存储为 LSA 密钥，并使用 LsaAddAccountRights 确保帐户拥有“Logon as batch job”的权限。（有关具体操作的示例，请参见 Platform SDK 中的 DCOMPERM 示例。请特别注意名为 SetRunAsPassword 和 SetAccountRights 的函数。） DCOM 不适于防火墙 关于 DCOM 特性和功能的一个常见问题是：“它能跨 Internet 工作吗？”DCOM 能够很好地跨 Internet 工作，只要将它配置为使用 TCP 或者 UDP，并且通过授予任何人启动和访问权限，可将服务器配置为允许匿名方法调用。毕竟，Internet 是一个巨大的 IP 网络。但矛盾的是，如果您将一个现有的 DCOM 应用程序（在公司的内部网络或 intranet 中工作得很好）改为跨 Internet 工作，它很有可能失败得很惨。可能是什么原因呢？防火墙。 DCOM 生来与防火墙的关系就如油与水的关系。原因之一是 COM 的 SCM 使用端口 135 与其他机器上的 SCM 通信。防火墙限制了它可以使用的端口和协议，可能会拒绝通过端口 135 传入的通信量。但更大的问题在于，为了避免与使用套接字、管道和其他 IPC 机制的应用程序冲突，DCOM 没有固定使用特定范围的端口，相反，它在运行时才选择所使用的端口。默认情况下，它可以使用从 1,024 到 65,535 范围内的任何端口。 允许 DCOM 应用程序通过防火墙的一种方式是，为 DCOM 要使用的协议打开端口 135 和端口 1,024-65,535。（默认情况下，Windows NT 4.0 是 UDP 协议，Windows 2000 是 TCP 协议。）但是，这比移除所有防火墙好不了多少。对此，您公司的 IT 人员可能要发表意见了。 另一种更安全和更现实的解决方案是，限制 DCOM 使用的端口范围，并只为 DCOM 通信量打开一组小范围端口。根据实践原则，您应该为每个服务器进程分配一个端口，将连接导出到远程 COM 客户端（不是每个接口指针一个端口或每个对象一个端口，而是每个服务器进程一个）。将 DCOM 配置为使用 TCP 而不是 UDP 是一个好方法，特别是在服务器对其客户端执行回调时。 DCOM 用于远程连接的端口范围和所用的协议可通过注册表进行配置。在 Windows 2000 和 Windows NT 4.0 Service Pack 4 或更高版本上，您可以用 DCOMCNFG 应用这些配置更改。以下是将 DCOM 配置为通过防火墙工作的办法。 图 3 选择协议
//////////////////////////////////////////////////////
// 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); 在此示例中，线程 A 封送了一个 IFoo 接口指针，并启动线程 B。线程 B 取消封送了该接口指针，并调用 IFoo::Bar。无论调用返回所花费的时间有多长，线程 A 都不会阻塞超过 5 秒钟，因为它在 WaitForSingleObject 的第二个参数中传递的是 5,000 （单位为微秒）。这并不是太好的办法，但是如果“无论在线路的另一端发生什么情况，线程 A 都不会挂起”这一点很重要的话，忍受这种麻烦也算值得。 共享对象并不容易 从我收到的邮件和在会议上被问到的问题判断，困扰许多 COM 程序员的一个问题是如何将两个或更多的客户端与一个对象实例连接。要回答这个问题，写出长篇大论（或是一本小册子）都很容易，但其实只要说明与现有对象的连接既不容易也不自动化，就足够了。COM 提供了大量创建对象的方式，包括很受欢迎的 CoCreateInstance(Ex) 函数。但是 COM 缺乏一种通用的命名服务，允许使用名称或 GUID 来标识对象实例。而且它没有提供内置的方式来创建对象，然后将它标识为调用的目标以检索接口指针。 这是不是意味着将多个客户端与单一对象实例连接就不可能了呢？当然不是。实现这一点有五种方式。在这些资源链接中，您可以找到更多信息甚至是示例代码，来指导您的操作。请注意，这些技术从一般意义上讲不能互换；通常，环境因素会决定哪种方式（如果有）适用于手边的任务： Singleton 对象 Singleton 对象就是只实例化一次的对象。可能会有 10 个客户端调用 CoCreateInstance 来“创建”Singleton 对象，但实际上，它们都是接收指向同一对象的接口指针。ATL COM 类可通过在其类的 声明中添加 DECLARE_CLASSFACTORY_SINGLETON 语句，来转换为 Singleton。 文件名字对象 如果一个对象实现了 IpersistFile，并在运行中对象表 (ROT) 中使用文件名字对象（它封装了传递给对象的 IPersistFile::Load 方法的文件名称）注册了自己，那么客户端就可以使用文件名字对象连接对象的现有实例了。实际上，文件名字对象允许使用文件名称来命名对象实例，对象可在这些文件名称中存储它们的持久性数据。它们甚至能够跨机器工作。 CoMarshalInterface 和 CoUnmarshalInterface 保存接口指针的 COM 客户端可以与其他客户端共享这些接口指针，只要它们愿意封送指针。COM 为愿意将接口指针封送给同一进程中其他线程的线程提供了优化（请参见教训 2），但是如果客户端线程属于其他进程，CoMarshalInterface 和 CoUnmarshalInterface 就是实现接口共享的关键途径了。有关讨论和示例代码，请参阅 MSJ 1999 年 8 月刊中我的超酷代码专栏。 自定义类对象 所有“可以在外部创建的”COM 对象都伴随有独立对象，称为类对象，它们的作用是创建所谓 COM 对象的实例。大多数类对象都要实现一个名为 IClassFactory 的接口，其中包括一个可以创建对象实例的名为 CreateInstance 的方法。（在底层，COM 将 CoCreateInstance(Ex) 调用转换为对 IClassFactory::CreateInstance 的调用）。IClassFactory 的问题在于，在检索指向以前创建的对象实例的接口指针时，它一点用处都没有。自定义类对象是实现替代 IClassFactory 的自定义激活接口的类对象。由于定义了接口，您还可以定义方法来检索对已由该类对象创建的对象的引用。更多信息和以 ATL 编写的示例，请参阅 1999 年 2 月的超酷代码专栏。 自定义名字对象 1999 年 11 月的超酷代码专栏介绍了允许使用 C 样式字符串命名对象实例的自定义名字对象类。将一个实例名称传递给 MkParseDisplayName，您就获得了一个与对象实例连接的名字对象。这些类型的名字对象的一个缺点是，它们在 Windows NT 4.0 中不能跨机器工作。 在使用这些方法中的任一个在客户端之间共享对象实例之前，请问自己一个问题：共享是必需的吗？如果方法调用从一个外部数据源（数据库、硬件设备，甚至可能是全局变量）检索数据以响应客户端的请求，那么为什么不为每个客户端分配一个对象实例，并允许每个实例访问数据源呢？您可能必须同步化对数据源的访问，但不一定要使用自定义类对象、自定义名字对象等手段。这就是用 Microsoft 事务服务 (MTS) 构建的应用程序的工作方式，从各种理由来看，它已经证明是一种引人注目的编程模型，而不仅仅是实现上的简便和性能的改善。 与我联系 您有什么困难的 Win32、MFC、MTS 或 COM(+) 编程问题需要解答吗？如果有，请给我发邮件，地址是 [email protected]。请在邮件主题中加上“Wicked Code”（超酷代码）字样。请原谅时间不允许我个别回答这些问题，但是对于每个问题，我都会考虑加入到未来的专栏内容中。 Jeff Prosise 是 Programming Windows with MFC（Microsoft Press，1999 年）一书的作者。他还是 Wintellect（一家软件咨询和教育公司）的创办人之一，该公司的网址是 http://www.wintellect.com。 |
| 摘自 MSDN Magazine 的 2000 年 11 月刊。此杂志可通过各地的报摊购买，也可以订阅。 |