Com 在使用IClassFactory:：LockServer（）时是否存在固有的争用条件？

我的理解是，IClassFactory:：LockServer（）的要点是，在某些情况下，为给定COM服务器提供一个活动的IClassFactory实例并不会阻止服务器卸载

---

既然如此，在CoGetClassObject（）返回的时间和调用LockServer（）的时间之间，是否有任何东西阻止服务器卸载？对我来说，这似乎是一个竞争条件，但我无法从粗略的谷歌搜索中找到任何关于它的信息。

CoGetClassObject

返回您的

IClassFactory

接口指针

对于进程内服务器，您持有此指针已经可以防止服务器卸载。

Lock

方法解决了在释放所有未完成的接口（包括有问题的

IClassFactory

指针！）之后和出现下一个实例创建请求之前加载/卸载/重新加载库的问题

进程外服务器自己创建和发布它们的类工厂，它们的类工厂不会影响服务器的锁定状态。也就是说，获取、引用和释放类工厂接口指针通常不会影响服务器的锁定状态（与

lock

方法不同）。这表明，在创建实际实例之前保持

IClassFactory

接口指针可能会使服务器处于不可加载状态，因此在

CreateInstance

调用时，服务器已经离开。然而，这正是COM API帮助保持服务器活动的地方

---

在进程外服务器的情况下，

IClassFactory

接口指针上的客户端接口指针引用会导致类工厂封送器提供的自动

IClassFactory:：LockServer

调用。以不同的方式，但它仍然是正确的：客户端持有有效的

IClassFactory

接口指针，阻止服务器卸载。

我明白了。看起来他们可能只是要求您保持IClassFactory实例的活动状态，这会更简单。我不知道我在哪里读到IClassFactory实例“不计算”。客户端通常不直接处理

IClassFactory

，而是使用像

CoCreateInstance

这样的API，它们在内部使用类工厂指针，并在使用后释放

Lock

方法提供了更长的锁。啊，但如果您使用类似于

CoCreateInstance

的东西，就不能调用

LockServer

。如果我没记错的话，类工厂通常不会让进程外服务器运行。否则，它将永远不会关闭-它首先调用

CoRegisterClassObject

，它拥有类工厂的强引用。因此，如果客户端想要保留

IClassFactory*

指针，它必须调用

LockServer

以防止服务器卸载-仅

AddRef

读取指针是不够的。对于进程内服务器，调用

LockServer

是不必要但无害的；只要保留一个

AddRef

ed

IClassFactory*

指针就足够了。我只是看了一下我的“Inside COM”副本，它基本上说明了Igor所做的事情，所以我就是从中得到这个想法的。如果他和这本书是正确的，那么我的问题就成立了。