What is the point of IClassFactory::LockServer?

Why does IClassFacto开发者_Python百科ry::LockServer exist when it seems to me that IClassFactory::AddRef / IClassFactory::Release can accomplish the same goal?

This is explained in detail in Don Box's book Essential COM.

AddRef/Release on IClassFactory interfaces of class objects are often empty methods in out-of-process COM servers. This is because an internal reference to the class object is maintained by the server when it calls CoRegisterClassObject, and thus the "normal" in-process server implementation of AddRef/Release would result in the reference count on the class object always exceeding one, and the server would not know when to call CoRevokeClassObject.

The COM runtime calls IClassFactory::LockServer when it marshals an external reference to a class object following a call to CoGetClassObject. In this way the server process lifetime can be properly controlled based on the existence or otherwise of external references.

I don't know for sure, but I think the idea is that you can call CoGetClassObject to get the class factory, lock it via its IClassFactory interface, and then release the interface. Later when you call CoGetClassFactory again for the same class, since it's been locked in memory the system will just return the same factory object rather than creating a new one. This could improve performance where you create a great many objects of that class.

Yes, you can achieve the same thing by holding onto the IClassFactory interface pointer. But by locking the factory object when your app starts up, and unlocking it on shutdown, you don't have to hold an interface pointer somewhere (in a global variable or whatever.)

I suspect the reason they introduced IClassFactory::LockServer was that locking the server is not semantically the same as AddRef'ing it. AddRef/Release is for normal object lifecycle management and has clearly defined semantics. Locking the server is a performance tweak.