CSDN博客

img Grrr

组件对象模型的规则

发表于2001/6/19 0:04:00  868人阅读

分类: COM

摘要

本文的目的是为使用和实行Microsoft的组件对象模型(COM)提供迅捷的参考。读者若想更好的理解什么是COM,以及隐藏在它的设计及体系中的动机,应该阅读开始的两章。它们是关于组件对象模型的技术说明书(MSDN库,技术说明书)。第一章是简要介绍,而第二章是提供了一个彻底的综述。此处的信息都来自于COM的技术说明书。

规则1必须实现Iunknown

如果一个对象没有至少实现一个最小程度为IUnknown的接口,那它就不是Microsoft的组件对象模型(COM)。

接口设计规则

接口必须直接或间接地从IUnknown继承。
接口必须有唯一的识别(IID)。
接口是不变的。一旦分配和公布了IID,接口定义的任何因素都不能被改变。
接口的成员函数应该有HRESULT类型的返回值,使远端结构可报告远程过程调用(RPC)错误的情况。
接口成员函数的字符串参数应该是Unicode。

实现 IUnknown

对象的同一性。这要求对任何特定IUnknown接口的给定对象实例的QueryInterface调用返回相同的物理指针变量。这导致了所谓的两个接口的QueryInterface(IID_IUnknown, ...)和结果的比较,以确定它们是否为同一对象(COM对象同一性)。
静态接口的设置。任何经由QueryInterface来访问对象的接口的设置,必须是静态而不是动态的。也就是说,假如一旦QueryInterface获得了一个给定的IID,那么它总是对相同的对象(除非有意想不到情况)调用,假如QueryInterface不能获得一个给定的IID,那么随后对相同IID的对象调用必定会失败。
对象完整性。对于可处理的接口设置,必须有反身性,对称性和过渡性。即给定代码如下:
IA * pA = (some function returning an IA*);
IB * pB = NULL;
HRESULT hr;
hr = pA->QueryInterface(IID_IB,&pB); // line 4
Symmetric: pA->QueryInterface(IID_IA, ...) must succeed (a>>a)
Reflexive: If, in line 4, pB was successfully obtained, then
pB->QueryInterface(IID_IA, ...)
must succeed (a>>b, then b>>a).
Transitive: If, in line 4, pB was successfully obtained, and we do
IC * pC = NULL;
hr = pB->QueryInterface(IID_IC, &pC); //Line 7
and pC is successfully obtained in line 7,then
pA->QueryInterface(IID_IC, ...)
must succeed (a>>b, and b>>c,then a>>c).
最小参考服务大小。我们需要实现AddRef来维护一个服务台,它足够大以便支持给定对象的所有接口的2 31 –1有出色的整体指示服务。一个32-位的无符号整型数满足要求。
Release并不意味着失败。假如客户想知道关于资源已被释放等情况,就必须在调用Release之前使用一些对象接口中的较高的语义。

内存管理规则

接口指针的生命期管理总是通过建立在每个COM接口上的AddRef和Release方法来实现。(参见下面的“引用计数规则”)
下面的规则适用于接口成员函数的参数,包括不是“按值”传递的返回值。
对于参数来说,调用程序应分配和释放内存。
出口参数必须由被调用程序分配,由调用程序用标准的COM内存分配程序来释放。
出入参数首先由调用程序分配,必要时由被调用程序释放及重分配。至于出口参数,调用程序有责任释放最终返回变量。此时必须使用标准的COM内存分配程序。
假如函数返回调用失败的代码,则通常调用者没办法清除出口和入出口参数。这导致了一些附加规则:
错误返回时,出口参数必须可靠地被设置成可清除变量,它不能对调用程序有影响。
此外,所有的出口指针参数(包括调用分配,被调用委任结构)必须被明显地设为NULL。最直接的方法是在函数说明项中设成NULL。
返回错误时,所有的入出口参数必须为被调用者所搁置(这样保持为调用程序初始化的值;若调用程序没有对它初始化,则它是个出口参数,不是入出口参数),或者被明显地设为出口错误返回情况。

参考计数规则:

规则1:对于接口指针的每一个新的副本,AddRef必须被调用;Release在接口指针的每一个破坏时调用,除了子规则明显允许了其他情况。
以下规则对应于规则1的非例外情况。
规则1a:函数的入口出口参数。调用程序必须AddRef实际参数,因为当出口变量存放在它之上时,将由被调程序释放。
规则1b:获取全局变量。从全局变量的已存在的指针副本得到的接口指针的局部副本,必须被独立地引用计数。因为存在局部副本时,被调函数会破坏全局副本。
规则1c:新指针合成所需资源不多。函数使用内在知识合成接口指针,而不是从其他资源所得,此时必须对新指针做初始AddRef。这样的重要例子有事例生成法则,Iunknown::QueryInterface的实现,等等。
规则1d:内部存储指针副本的返回。指针返回之后,被调程序不知道它的生命期和指针的内部存储副本如何联系。所以,被调程序必须在返回前对指针副本调用AddRef。
规则2:对于接口指针的两个或更多的副本,它们的生命期的起始和终了的关系代码的特定知识,使AddRef/Release可以被省略。
从COM客户的角度,引用计数是和接口对应的概念。客户不应认为对象的所有接口有同一引用计数。
不应依赖于Addref & Release的返回值,而应用于调试目的。
指针稳定性;参见在"Reference-Counting Rules"下的OLE帮助文件中的子部分:"Stabilizing the this Pointer and Keeping it Valid"。
参见Douglas Hodges写的优秀的技术文章"Managing Object Lifetimes in OLE",及Kraig Brockschmidt (MSDN Library, Books)写的Inside OLE的第三章来获取更多信息。

COM申请责任:

以客户,服务器,对象执行者之一身份使用COM的每一进程,要对三件事负责:
确定COM库是同COM函数CoBuildVersion一致的版本。
在使用其他函数之前通过调用CoInitialize初始化COM库。
在不用CoUninitialize时取消COM库的初始化。
进程内服务器能假定载入的进程已执行了这些步骤。

服务器规则

进程内服务器必须输出DllGetClassObject and DllCanUnloadNow。
进程内服务器必须支持COM自注册。
进程内和局部服务器应该在它们的文件版本信息中提供OLESelfReg字符串。
进程内服务器必须输出DllRegisterServer and DllUnRegisterServer。
局部服务器应支持/RegServer and /UnRegServer命令行开关。

生成集合对象

生成可合计的对象是可选的,且操作简单,有诸多益处。以下规则使用于创建可合计的对象(通常称为内部对象)。
由QueryInterface, AddRef, 和 Release对IUnknown接口的内部对象执行单独控制内部接口的引用计数,且不能授权给外部未知指针。这种IUnknown执行称为隐式IUnknown。
内部对象执行接口的QueryInterface, AddRef, 和 Release成员的实行,除了IUnknown自己,都必须授权给外部未知指针。这些实施不能直接影响内部对象的参考计数。
隐式Iunknown只对内部对象实施QueryInterface操作。
集合对象在占用外部未知指针参考时,不能调用AddRef。
如果当对象创建时,需要除Iunknown外的任一接口,创建失败同E_UBKNOWN一起。
以下的代码段阐明了使用嵌套类来实现集合对象接口的范例:
// CSomeObject is an aggregatable object that implements
// IUnknown and ISomeInterface
class CSomeObject : public IUnknown
{
private:
DWORD m_cRef;// Object reference count
IUnknown* m_pUnkOuter; //Outer unknown, no AddRef
// Nested class to implement the ISomeInterface interface
class CImpSomeInterface: public ISomeInterface
{
friend class CSomeObject ;
private:
private:DWORD m_cRef; //Interface ref-count, for debugging
private:IUnknown*m_pUnkOuter; // Outerunknown, for delegation
private:public:
private:CImpSomeInterface() { m_cRef = 0; };
private:~ CImpSomeInterface(void) {};
private:// IUnknown members delegate to the outer unknown
private:// IUnknown members do not control lifetime of object
private:STDMETHODIMP QueryInterface(REFIID riid, void** ppv)
private:{ return m_pUnkOuter->QueryInterface(riid,ppv);};
private:STDMETHODIMP_(DWORD) AddRef(void)
private:{ return m_pUnkOuter->AddRef(); };
private:STDMETHODIMP_(DWORD) Release(void)
private:{ return m_pUnkOuter->Release();};
private:// ISomeInterface members
private:STDMETHODIMP SomeMethod(void)
private:{ return S_OK; };
private:} ;
private:CImpSomeInterface m_ImpSomeInterface ;
private:public:
private:CSomeObject(IUnknown * pUnkOuter)
{
m_cRef=0;
// No AddRef necessary if non-NULL as we're aggregated.
m_pUnkOuter=pUnkOuter;
m_ImpSomeInterface.m_pUnkOuter=pUnkOuter;
} ;
// Static member function for creating new instances (don't use
// new directly).Protects against outer objects asking for interfaces
// other than IUnknown
static HRESULT Create(IUnknown* pUnkOuter, REFIID riid, void **ppv)
{
CSomeObject* pObj;
if (pUnkOuter != NULL && riid != IID_IUnknown)
return CLASS_E_NOAGGREGATION;
pObj = new CSomeObject(pUnkOuter);
if (pObj == NULL)
return E_OUTOFMEMORY;
// Set up the right unknown for delegation (the non-aggregation
case)
if (pUnkOuter == NULL)
pObj->m_pUnkOuter = (IUnknown*)pObj ;
HRESULT hr;
if (FAILED(hr = pObj->QueryInterface(riid, (void**)ppv)))
delete pObj ;
return hr;
}
// Implicit IUnknown members, non-delegating
// Implicit QueryInterface only controls inner object
STDMETHODIMP QueryInterface(REFIID riid, void** ppv)
{
*ppv=NULL;
if (riid == IID_IUnknown)
*ppv=this;
if (riid == IID_ISomeInterface)
*ppv=&m_ImpSomeInterface;
if (NULL==*ppv)
return ResultFromScode(E_NOINTERFACE);
((IUnknown*)*ppv)->AddRef();
return NOERROR;
} ;
STDMETHODIMP_(DWORD)AddRef(void)
{ return++m_cRef; };
STDMETHODIMP_(DWORD)Release(void)
{
if (--m_cRef != 0)
return m_cRef;
delete this;
return 0;
};
};

集合对象

当在一个对象上产生另一个集合对象时,必须遵循以下规则:

  • 当创建一个内部对象时,外部对象必须明确的向Iunknown请求。
  • 外部对象必须保护重入时对破坏代码的人工引用的Release实施。
  • 如果外部对象查询任一内部对象接口,它必须调用自己的未知Release。释放此指针时,外部对象紧随内部对象指针调用自己的外部未知AddRef。

// Obtaining inner object interface pointer
pUnkInner->QueryInterface(IID_IFoo,&pIFoo);
pUnkOuter->Release();
// Releasing inner object interface pointer
pUnkOuter->AddRef();
pIFoo->Release();
外部对象不能盲目地对内部对象的未被识别接口进行查询,除非操作是为外部对象特定目的。

房间线程化模型

房间模型线程化的细节实际上非常简单,但是必须小心地遵循以下规则:
每个对象存在于单线程中(在单独的房间中)。
所有对一对象的调用必须基于自己的线程(在自己的房间中)。直接从别的线程中调用对象是禁止的。试图用空线程方式使用对象的申请,将在操作系统的未来版本中遇上不能正确运行的问题。这条规则的含义就是在房间之间,必须安排对象的所有指针。
为了处理从不同进程或同一进程的不同房间中的调用,在对象中的每一房间/线程必须有一个消息队列。这就意味着线程的工作函数必须有一个GetMessage/DispatchMessage循环。假如在线程之间有别的同步原语用来通信,那么Microsoft Win32的sgWaitForMultipleObjects将被用来等待消息和线程同步事件。
基于DLL或进程内的对象必须在注册表中标记为"房间识别",通过给注册数据库的InprocServer32关键字增添名为"ThreadingModel=Apartment"的变量实现。
房间识别对象应仔细填写DLL表项。对房间识别对象调用CoCreateInstance的每一个房间将从它的线程调用DllGetClassObject。故DllGetClassObject应能多级类对象或单线程安全对象。从任一线程调用CoFreeUnusedLibraries,都通过主房间线程来调用DllCanUnloadNow.。

0 0

相关博文

我的热门文章

img
取 消
img