Страница:
Для того чтобы объект можно было использовать в обоих сценариях – агрегирования и автономном – разработчик объекта должен установить свой элемент данных m_pUnkOuter так, чтобы в случае автономного режима он указывал на собственный неделегирующий IUnknown:
Car::Car(IUnknown *pUnkOuter)
{
if (pUnkOuter)
// delegate to pUnkOuter
// делегируем в pUnkOuter
m_pUnkOuter = pUnkOuter;
else // delegate to non-delegating self
// делегируем неделегирующему себе m_pUnkOuter = &m_innerUnknown;
}
Разработчик обеспечивает то, что в обоих случаях m_pUnkOuter указывает на нужную для данного объекта реализацию QueryInterface, AddRef и Release.
Обычные неделегирующие реализации QueryInterface, AddRef и Release являются вполне правильными и предсказуемыми:
STDMETHODIMP Car::InternalQueryInterface(REFIID riid, void **ppv)
{
if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(&m_innerUnknown);
else if (riid = IID_IVehicle) *ppv = static_cast<IVehicle*>(this);
else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this);
else return (*ppv = 0), E_NOINTERFACE;
((IUnknown*)*ppv)->AddRef();
return S_OK;
}
STDMETHODIMP_(ULONG) Car::InternalAddRef(void)
{
return InterlockedIncrement(&m_cRef);
}
STDMETHODIMP_(ULONG) Car::InternalRelease(void)
{
ULONG res = InterlockedDecrement(&m_cRef);
if (res == 0) delete this;
return res;
}
Единственной отличительной особенностью этих трех методов (кроме их имен) является то, что InternalQueryInterface при запросе IUnknown возвращает указатель на неделегирующую Unknown. Это просто требование Спецификации СОМ, которого следует придерживаться.
И наконец, подпрограмму создания Car требуется модифицировать для поддержки агрегирования:
STDMETHODIMP CarClass::CreateInstance(IUnknown *punk0uter, REFIID riid, void **ppv)
{
// verify that aggregator only requests IUnknown as
// initial interface
// проверяем, что агрегатор только запрашивает IUnknown как
// начальный интерфейс
if (pUnkOuter != 0 && riid != IID_IUnknown)
return (*ppv = 0), E_INVALIDARG;
// create new object/aggregate
// создаем новый объект или агрегат Car
*р = new Car(pUnkOuter);
if (!p) return (*ppv = 0), E_OUTOFMEMORY;
// return resultant pointer
// возвращаем результирующий указатель
p->InternalAddRef();
HRESULT hr = p->InternalQueryInterface(riid, ppv);
p->InternalRelease();
return hr;
}
Отметим, что здесь используются неделегирующие версии QueryInterface, AddRef и Release. Если создается автономная идентификационная единица, то это, конечно, допустимо. Если же создается агрегат, то необходимо убедиться, что AddRef обработал внутренний, а не внешний объект. Отметим также, что внешний объект в качестве начального интерфейса должен запросить IUnknown. Все это регламентировано Спецификацией СОМ. Если бы внешний объект мог запрашивать произвольный начальный интерфейс, то внутреннему объекту пришлось бы хранить два дублирующих набора указателей vptr: один набор делегировал бы свои реализации QueryInterface, AddRef и Release, а другой – нет. При допущении в качестве начального интерфейса одного IUnknown разработчик объекта может выделить только один vptr, который будет действовать как неделегирующий IUnknown.
При программировании с СОМ-агрегированием может возникнуть опасность, связанная со счетчиком ссылок. Отметим, что разработчик внутреннего объекта дублирует указатель на управляющий внешний объект, но не вызывает AddRef. Вызов AddRef в данной ситуации запрещен, поскольку если оба объекта будут обрабатывать друг друга посредством AddRef, то получится бесконечный цикл. Правила подсчета ссылок при агрегировании требуют, чтобы внешний объект хранил указатель на внутренний неделегирующий IUnknown объекта (это указатель, возвращенный подпрограммой создания объекта) после подсчета ссылок на этот указатель. Внутренний объект хранит указатель на IUnknown управляющего внешнего объекта с неподсчитанными ссылками. Формально эти соотношения зафиксированы в специальной формулировке правил СОМ для счетчиков ссылок. Вообще-то методику использования указателей без подсчета ссылок применять нельзя, поскольку ее невозможно реализовать в случае удаленного доступа к объектам. Более эффективный способ избежать зацикливания счетчика ссылок состоит в том, чтобы ввести промежуточные идентификационные единицы (identities) объектов, счетчики ссылок которых не повлияют на время жизни никакого объекта.
Еще одна проблема при программировании агрегирования может возникнуть, когда необходимо связать между собой внутренний и внешний объекты. Для того чтобы организовать связь внутреннего объекта с внешним, нужно вызвать QueryInterface посредством управляющего IUnknown. Однако этот запрос QueryInterface вызовет AddRef через результирующий указатель, который имеет обыкновение без спросу обрабатывать внешний объект с помощью AddRef. Если бы внутренний объект хранил этот указатель в качестве элемента данных, то возник бы цикл, поскольку внутренний объект уже неявно обработал внешний объект с помощью AddRef. Это означает, что внутренний объект должен избрать одну из двух стратегий. Внутренний объект может получать и освобождать указатель по потребности, храня его ровно столько времени, сколько это необходимо:
STDMETHODIMP Inner::MethodX(void)
{
ITruck *pTruck = 0;
// outer object will be AddRefed after this call…
// после этого вызова внешний объект будет обработан
// с помощью AddRef…
HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&pTruck);
if (SUCCEEDED(hr))
{
pTruck->ShiftGears();
pTruck->HaulDirt();
// release reference to outer object
// освобождаем ссылку на внешний объект pTruck->Release();
}
}
Второй способ заключается в том, чтобы получить указатель один раз во время инициализации и освободить соответствующий внешний объект немедленно после получения.
HRESULT Inner::Initialize(void)
{
// outer object will be AddRefed after this call…
// после этого вызова внешний объект будет обработан
// с помощью AddRef…
HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&m_pTruck);
// release reference to outer object here and DO NOT
// release it later in the object's destructor
// освобождаем здесь ссылку на внешний объект и
// НЕ ОСВОБОЖДАЕМ ее потом в деструкторе объекта
if (SUCCEEDED(hr)) m_pTruck->Release();
}
Этот способ работает, поскольку время жизни внутреннего объекта является точным подмножеством времени жизни внешнего объекта. Это означает, что m_pTruck будет теоретически всегда указывать на существующий объект. Конечно, если внешний объект реализовал ITruck как отделяемый интерфейс, то все предыдущее неверно, так как вызов Release уничтожит этот отделяемый интерфейс.
Объекты, которые агрегируют другие объекты, должны быть в курсе проблем, возникающих при запросе интерфейсных указателей внутренними объектами агрегата. В дополнение к уже сделанному предостережению относительно отделяемых интерфейсов отметим еще одну возможную опасность, связанную со стабилизацией объекта. Когда клиенты обращаются к объекту, он должен находиться в стабильном состоянии. В частности, его счетчик ссылок не должен равняться нулю. В общем случае это не является проблемой, так как клиенты могут получать интерфейсные указатели только через QueryInterface, который всегда освобождает AddRef раньше, чем возврат. Однако если объект создает агрегат в своем разработчике, в то время как его счетчик ссылок объекта равен нулю, то программа инициализации внутреннего объекта, показанная выше, освободит завершающее освобождение внешнего объекта, побуждая тем самым внешний объект к преждевременному самоуничтожению. Чтобы устранить эту проблему, объекты, агрегирующие другие объекты, временно увеличивают свои счетчики ссылок на единицу на время создания агрегируемых объектов:
Outer::Outer(void)
{
++m_cRef;
// protect against delete this
// защищаем против удаления this
CoCreateInstance(CLSID_Inner, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkInner);
–m_cRef;
// allow delete this
// позволяем удалить this }
Данная методика стабилизации предотвращает преждевременное разрушение, когда внутренний объект освобождает указатели, которые он, быть может, получил в свой код инициализации. Эта методика настолько общепринята, что большинство СОМ-оболочек программирования включают в себя явный метод перекрытия (overridable), который работает внутри области действия пары инкремент/декремент. В MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) этот метод называется CreateAggregates, в ATL – FinalConstruct.
Поскольку показанные выше методики реализации агрегируемого объекта не требуют никаких дополнительных базовых классов, кроме классов C++, то альтернативная форма макроса IMPLEMENT_UNKNOWN может прозрачно реализовать раздвоенную реализацию IUnknown. Определение исходного класса:
class Car : public ICar
{
Car(void);
IMPLEMENT_UNKNOWN(Car)
BEGIN_INTERFACE_TABLE(Car)
IMPLEMENTS_INTERFACE(ICar)
IMPLEMENTS_INTERFACE(IVehicle)
END_INTERFACE()
// IVehicle methods
// методы IVehicle
STDMETHODIMP GetMaxSpeed(long *pn);
// ICar methods
// методы ICar
STDMETHODIMP Brake(void);
};
просто переводится в следующее:
class Car : public ICar
{
Car(void);
//indicate that aggregation is required
// показываем, что требуется агрегирование
IMPLEMENT_AGGREGATABLE_UNKNOWN(Car)
BEGIN_INTERFACE_TABLE(Car)
IMPLEMENTS_INTERFACE(ICar)
IMPLEMENTS_INTERFACE(IVehicle)
END_INTERFACE()
// IVehicle methods
// методы IVehicle
STDMETHODIMP GetMaxSpeed(long *pn);
// ICar methods
// методы ICar
STDMETHODIMP Brake(void);
};
Встроенное расширение макроса IMPLEMENT_AGGREGATABLE_UNKNOWN включено в код, приложенный к этой книге.
Включение
Где мы находимся?
Глава 5. Апартаменты
Снова интерфейс и реализация
Объекты, интерфейсы и апартаменты
Car::Car(IUnknown *pUnkOuter)
{
if (pUnkOuter)
// delegate to pUnkOuter
// делегируем в pUnkOuter
m_pUnkOuter = pUnkOuter;
else // delegate to non-delegating self
// делегируем неделегирующему себе m_pUnkOuter = &m_innerUnknown;
}
Разработчик обеспечивает то, что в обоих случаях m_pUnkOuter указывает на нужную для данного объекта реализацию QueryInterface, AddRef и Release.
Обычные неделегирующие реализации QueryInterface, AddRef и Release являются вполне правильными и предсказуемыми:
STDMETHODIMP Car::InternalQueryInterface(REFIID riid, void **ppv)
{
if (riid == IID_IUnknown) *ppv = static_cast<IUnknown*>(&m_innerUnknown);
else if (riid = IID_IVehicle) *ppv = static_cast<IVehicle*>(this);
else if (riid == IID_ICar) *ppv = static_cast<ICar*>(this);
else return (*ppv = 0), E_NOINTERFACE;
((IUnknown*)*ppv)->AddRef();
return S_OK;
}
STDMETHODIMP_(ULONG) Car::InternalAddRef(void)
{
return InterlockedIncrement(&m_cRef);
}
STDMETHODIMP_(ULONG) Car::InternalRelease(void)
{
ULONG res = InterlockedDecrement(&m_cRef);
if (res == 0) delete this;
return res;
}
Единственной отличительной особенностью этих трех методов (кроме их имен) является то, что InternalQueryInterface при запросе IUnknown возвращает указатель на неделегирующую Unknown. Это просто требование Спецификации СОМ, которого следует придерживаться.
И наконец, подпрограмму создания Car требуется модифицировать для поддержки агрегирования:
STDMETHODIMP CarClass::CreateInstance(IUnknown *punk0uter, REFIID riid, void **ppv)
{
// verify that aggregator only requests IUnknown as
// initial interface
// проверяем, что агрегатор только запрашивает IUnknown как
// начальный интерфейс
if (pUnkOuter != 0 && riid != IID_IUnknown)
return (*ppv = 0), E_INVALIDARG;
// create new object/aggregate
// создаем новый объект или агрегат Car
*р = new Car(pUnkOuter);
if (!p) return (*ppv = 0), E_OUTOFMEMORY;
// return resultant pointer
// возвращаем результирующий указатель
p->InternalAddRef();
HRESULT hr = p->InternalQueryInterface(riid, ppv);
p->InternalRelease();
return hr;
}
Отметим, что здесь используются неделегирующие версии QueryInterface, AddRef и Release. Если создается автономная идентификационная единица, то это, конечно, допустимо. Если же создается агрегат, то необходимо убедиться, что AddRef обработал внутренний, а не внешний объект. Отметим также, что внешний объект в качестве начального интерфейса должен запросить IUnknown. Все это регламентировано Спецификацией СОМ. Если бы внешний объект мог запрашивать произвольный начальный интерфейс, то внутреннему объекту пришлось бы хранить два дублирующих набора указателей vptr: один набор делегировал бы свои реализации QueryInterface, AddRef и Release, а другой – нет. При допущении в качестве начального интерфейса одного IUnknown разработчик объекта может выделить только один vptr, который будет действовать как неделегирующий IUnknown.
При программировании с СОМ-агрегированием может возникнуть опасность, связанная со счетчиком ссылок. Отметим, что разработчик внутреннего объекта дублирует указатель на управляющий внешний объект, но не вызывает AddRef. Вызов AddRef в данной ситуации запрещен, поскольку если оба объекта будут обрабатывать друг друга посредством AddRef, то получится бесконечный цикл. Правила подсчета ссылок при агрегировании требуют, чтобы внешний объект хранил указатель на внутренний неделегирующий IUnknown объекта (это указатель, возвращенный подпрограммой создания объекта) после подсчета ссылок на этот указатель. Внутренний объект хранит указатель на IUnknown управляющего внешнего объекта с неподсчитанными ссылками. Формально эти соотношения зафиксированы в специальной формулировке правил СОМ для счетчиков ссылок. Вообще-то методику использования указателей без подсчета ссылок применять нельзя, поскольку ее невозможно реализовать в случае удаленного доступа к объектам. Более эффективный способ избежать зацикливания счетчика ссылок состоит в том, чтобы ввести промежуточные идентификационные единицы (identities) объектов, счетчики ссылок которых не повлияют на время жизни никакого объекта.
Еще одна проблема при программировании агрегирования может возникнуть, когда необходимо связать между собой внутренний и внешний объекты. Для того чтобы организовать связь внутреннего объекта с внешним, нужно вызвать QueryInterface посредством управляющего IUnknown. Однако этот запрос QueryInterface вызовет AddRef через результирующий указатель, который имеет обыкновение без спросу обрабатывать внешний объект с помощью AddRef. Если бы внутренний объект хранил этот указатель в качестве элемента данных, то возник бы цикл, поскольку внутренний объект уже неявно обработал внешний объект с помощью AddRef. Это означает, что внутренний объект должен избрать одну из двух стратегий. Внутренний объект может получать и освобождать указатель по потребности, храня его ровно столько времени, сколько это необходимо:
STDMETHODIMP Inner::MethodX(void)
{
ITruck *pTruck = 0;
// outer object will be AddRefed after this call…
// после этого вызова внешний объект будет обработан
// с помощью AddRef…
HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&pTruck);
if (SUCCEEDED(hr))
{
pTruck->ShiftGears();
pTruck->HaulDirt();
// release reference to outer object
// освобождаем ссылку на внешний объект pTruck->Release();
}
}
Второй способ заключается в том, чтобы получить указатель один раз во время инициализации и освободить соответствующий внешний объект немедленно после получения.
HRESULT Inner::Initialize(void)
{
// outer object will be AddRefed after this call…
// после этого вызова внешний объект будет обработан
// с помощью AddRef…
HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&m_pTruck);
// release reference to outer object here and DO NOT
// release it later in the object's destructor
// освобождаем здесь ссылку на внешний объект и
// НЕ ОСВОБОЖДАЕМ ее потом в деструкторе объекта
if (SUCCEEDED(hr)) m_pTruck->Release();
}
Этот способ работает, поскольку время жизни внутреннего объекта является точным подмножеством времени жизни внешнего объекта. Это означает, что m_pTruck будет теоретически всегда указывать на существующий объект. Конечно, если внешний объект реализовал ITruck как отделяемый интерфейс, то все предыдущее неверно, так как вызов Release уничтожит этот отделяемый интерфейс.
Объекты, которые агрегируют другие объекты, должны быть в курсе проблем, возникающих при запросе интерфейсных указателей внутренними объектами агрегата. В дополнение к уже сделанному предостережению относительно отделяемых интерфейсов отметим еще одну возможную опасность, связанную со стабилизацией объекта. Когда клиенты обращаются к объекту, он должен находиться в стабильном состоянии. В частности, его счетчик ссылок не должен равняться нулю. В общем случае это не является проблемой, так как клиенты могут получать интерфейсные указатели только через QueryInterface, который всегда освобождает AddRef раньше, чем возврат. Однако если объект создает агрегат в своем разработчике, в то время как его счетчик ссылок объекта равен нулю, то программа инициализации внутреннего объекта, показанная выше, освободит завершающее освобождение внешнего объекта, побуждая тем самым внешний объект к преждевременному самоуничтожению. Чтобы устранить эту проблему, объекты, агрегирующие другие объекты, временно увеличивают свои счетчики ссылок на единицу на время создания агрегируемых объектов:
Outer::Outer(void)
{
++m_cRef;
// protect against delete this
// защищаем против удаления this
CoCreateInstance(CLSID_Inner, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkInner);
–m_cRef;
// allow delete this
// позволяем удалить this }
Данная методика стабилизации предотвращает преждевременное разрушение, когда внутренний объект освобождает указатели, которые он, быть может, получил в свой код инициализации. Эта методика настолько общепринята, что большинство СОМ-оболочек программирования включают в себя явный метод перекрытия (overridable), который работает внутри области действия пары инкремент/декремент. В MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) этот метод называется CreateAggregates, в ATL – FinalConstruct.
Поскольку показанные выше методики реализации агрегируемого объекта не требуют никаких дополнительных базовых классов, кроме классов C++, то альтернативная форма макроса IMPLEMENT_UNKNOWN может прозрачно реализовать раздвоенную реализацию IUnknown. Определение исходного класса:
class Car : public ICar
{
Car(void);
IMPLEMENT_UNKNOWN(Car)
BEGIN_INTERFACE_TABLE(Car)
IMPLEMENTS_INTERFACE(ICar)
IMPLEMENTS_INTERFACE(IVehicle)
END_INTERFACE()
// IVehicle methods
// методы IVehicle
STDMETHODIMP GetMaxSpeed(long *pn);
// ICar methods
// методы ICar
STDMETHODIMP Brake(void);
};
просто переводится в следующее:
class Car : public ICar
{
Car(void);
//indicate that aggregation is required
// показываем, что требуется агрегирование
IMPLEMENT_AGGREGATABLE_UNKNOWN(Car)
BEGIN_INTERFACE_TABLE(Car)
IMPLEMENTS_INTERFACE(ICar)
IMPLEMENTS_INTERFACE(IVehicle)
END_INTERFACE()
// IVehicle methods
// методы IVehicle
STDMETHODIMP GetMaxSpeed(long *pn);
// ICar methods
// методы ICar
STDMETHODIMP Brake(void);
};
Встроенное расширение макроса IMPLEMENT_AGGREGATABLE_UNKNOWN включено в код, приложенный к этой книге.
Включение
Не все классы способны к агрегированию. Для того чтобы выставить неагрегируемые классы как часть индивидуальности другого объекта, необходимо, чтобы внешние объекты явно передавали вызовы методов внутренним объектам. Эта технология СОМ часто называется включением (containment).
Как показано на рис. 4.9, включение не требует никакого участия со стороны внутреннего объекта. В то же время требуется, чтобы во внешнем объекте производились реализации каждого интерфейса, выставляемого внутренним объектом. Эти внешние реализации просто передают клиентские запросы внутреннему объекту. Включение СОМ не требует никаких особых забот касательно правил идентификации СОМ, так как внутренний объект никогда не доступен клиенту впрямую и поэтому никогда непосредственно не внедряется в иерархию типов внешнего объекта. Хотя СОМ-включение входит в терминологию СОМ, оно не требует никаких особых программистских ухищрений. Фактически включаемый объект не может обнаружить, что внешний объект переадресовывает запросы его методов от действующего клиента.
Как показано на рис. 4.9, включение не требует никакого участия со стороны внутреннего объекта. В то же время требуется, чтобы во внешнем объекте производились реализации каждого интерфейса, выставляемого внутренним объектом. Эти внешние реализации просто передают клиентские запросы внутреннему объекту. Включение СОМ не требует никаких особых забот касательно правил идентификации СОМ, так как внутренний объект никогда не доступен клиенту впрямую и поэтому никогда непосредственно не внедряется в иерархию типов внешнего объекта. Хотя СОМ-включение входит в терминологию СОМ, оно не требует никаких особых программистских ухищрений. Фактически включаемый объект не может обнаружить, что внешний объект переадресовывает запросы его методов от действующего клиента.
Где мы находимся?
В данной главе обсуждались законы идентификации в СОМ. В этих законах определено, что означает быть объектом СОМ. Законы идентификации СОМ предоставляют разработчику объекта потрясающую гибкость при разделении реализации объекта. В качестве технологии для освобождения подсчета ссылок для каждого интерфейса была представлена композиция. Для сокращения размножения vptr, а также для более эффективного управления состоянием объекта были описаны отделяемые интерфейсы. Затем было показано агрегирование в качестве способа создания одной идентификационной единицы (identity ) из двух или более двоичных компонентов. Каждая из этих технологий позволяет более чем одному объекту выступать в качестве одной идентификационной единицы СОМ. Каждая технология имеет свои преимущества, и использование любой из них или всех вместе полностью скрыто от клиентов объекта.
Глава 5. Апартаменты
STDMETHODIMP CMyClass::MethodX(void) {
EnterCr1t1calSect1on(&m_cs);
if (TryToPerformX() == false)
return E_UNEXPECTED:
LeaveCriticalSect1on(&m_cs);
return S_OK; }
Аноним, 1996
В предыдущей главе обсуждались основы идентификации в СОМ и было формально определено, что именно отличает объекты СОМ от объектов памяти с произвольной организацией. Были представлены правила IUnknown и способы использования этих правил для придания разработчику объектов максимальной гибкости. В данной главе уточняется понятие идентификации в СОМ с учетом базисных элементов (примитивов) операционной системы (например, потоков, процессов), а также распределенного доступа. Этот альянс базисных элементов системы и распределения формируют основу архитектуры удаленного доступа СОМ.
Снова интерфейс и реализация
Некоторые разработчики всесторонне используют многопоточные программные технологии и способны написать удивительно изощренный программный продукт с использованием примитивов синхронизации потоков, доступных из операционной системы. Другие разработчики больше сконцентрированы на решении вопросов, специфических для их области, и не утруждают себя написанием нудного потоко-безопасного кода. Третьи разработчики имеют особые ограничения по организации потоков, связанные с тем, что многие системы с управлением окнами (включая Windows) имеют очень строгие правила взаимодействия потоков и оконных примитивов. Еще один класс разработчиков может широко использовать старую библиотеку классов, которая неприязненно относится к потокам и не может допустить какого бы то ни было многопоточного обращения. У всех четырех типов разработчиков должна быть возможность использования объектов друг друга без перестраивания их потоковой стратегии, чтобы приспособиться ко всем возможным сценариям. Чтобы облегчить прозрачное использование объекта безотносительно к его осведомленности о потоках, СОМ рассматривает ограничения на параллелизм объектов как еще одну деталь реализации, о которой клиенту не нужно беспокоиться. Чтобы освободить клиента от ограничений параллелизма и реентерабельности (повторной входимости), в СОМ имеется весьма формальная абстракция, которая моделирует связь объектов с процессами и потоками. Эта абстракция носит название апартамент (apartment)[1] . Апартаменты определяют логическое группирование объектов, имеющих общий набор ограничений по параллелизму и реентерабельности. Каждый объект СОМ принадлежит к ровно одному апартаменту: один апартамент, однако, может быть общим для многих объектов. Апартамент, к которому относится объект, безоговорочно является частью идентификационной уникальности объекта.
Апартамент не является ни процессом, ни потоком; но в то же время апартаменты обладают некоторыми свойствами обоих этих понятий. Каждый процесс, использующий СОМ, имеет один апартамент или более; тем не менее, апартамент содержится ровно в одном процессе. Это означает, что каждый процесс, использующий СОМ, имеет как минимум одну группу объектов, которая удовлетворяет требованиям параллелизма и реентерабельности; однако два объекта, находящихся в одном и том же процессе, могут принадлежать к двум различным апартаментам и поэтому иметь разные ограничения по параллелизму и реентерабельности. Этот принцип позволяет библиотекам с совершенно различными понятиями о потоках мирно соучаствовать и одном общем процессе.
Поток одновременно выполняется в одном и только одном апартаменте. Для того чтобы поток мог использовать СОМ, он должен сначала войти в апартамент. Когда поток входит в апартамент, СОМ размещает информацию об апартаменте в локальной записи потока (TLS – thread local storage), и эта информация связана с потоком до тех пор, пока поток не покинет апартамент. СОМ обеспечивает доступ к объектам только для тех потоков, которые выполняются в апартаменте данного объекта. Это означает, что если поток выполняется в том же процессе, что и объект, то потоку может быть запрещено обращаться к объекту, даже если память, которую занимает объект, полностью видима и доступна. В СОМ определен HRESULT (RPC_E_WRONG_THREAD), который возвращают некоторые системные объекты при прямом обращении из других апартаментов. Объекты, определенные пользователем, также могут возвращать этот HRESULT; однако лишь немногие разработчики желают пройти столь долгий путь для обеспечения правильного использования своих объектов.
В версии СОМ под Windows NT 4.0 определяется два типа апартаментов: многопоточные апартаменты (МТА – multithreaded apartments) и однопоточные апартаменты (STA – singlethreaded apartments). В каждом процессе может быть не больше одного МТА; однако процесс может содержать несколько STA. Как следует из этих названий, в МТА может выполняться одновременно несколько потоков, а в STA – только один поток. Точнее, только один поток может когда-либо выполняться в данном STA; что означает не только то, что к объектам, находящимся в STA, никогда нельзя будет обратиться одновременно, но также и то, что только один определенный поток может когда-либо выполнять методы объекта. Эта привязка (affinity) к потоку позволяет разработчикам объекта надежно сохранять промежуточное состояние между вызовами метода в локальной памяти потока TLS (thread local storage), а также сохранять блокировки (locks), требующие поточной привязки (например, критические секции Win32 и семафоры (mutexes)).
Подобная практика приведет к катастрофе, если применять ее в случае объектов из МТА, так как в этом случае неизвестно, какой поток будет выполнять данный вызов метода. Неудобство STA заключается в том, что он позволяет одновременно выполняться только одному вызову метода, независимо от того, сколько объектов принадлежат к данному апартаменту. В случае МТА потоки могут быть распределены динамически на основании текущих запросов, вне зависимости от количества объектов в апартаменте. Для того чтобы создать параллельные серверные процессы с использованием только однопоточных апартаментов, потребуется много апартаментов, и если не соблюдать осторожность, то может возникнуть непомерное количество потоков. Кроме того, уровень параллелизма в основанных на STA обслуживающих процессах не может превышать общее число объектов в процессе. Если процесс сервера содержит только малое число крупномодульных (coarse-grained) объектов, то удастся обойтись малым числом потоков, даже если каждый объект существует в своем отдельном STA .
В будущей реализации СОМ будет, возможно, введен третий тип апартамента – апартамент, арендованный потоками (RTA – rentalthreaded apartment). Подобно МТА, RTA позволяет входить в апартамент более чем одному потоку. Но, в отличие от МТА , когда поток входит в RTA, он вызывает блокировку всего апартамента (apartment-wide lock) (то есть он как бы арендует апартамент), которая запрещает другим потокам одновременно входить в апартамент. Эта блокировка апартамента снимается, когда поток покидает RTA , что позволяет войти следующему потоку. В этом отношении RTA подобен МТА , за исключением того, что все вызовы методов осуществляются последовательно. Это обстоятельство делает RTA значительно удобнее для классов, относительно которых неизвестно, являются ли они потокобезопасными. Хотя все вызовы в STA также осуществляются сериями, объекты на основе RTA отличаются тем, что в них нет привязки потоков; то есть внутри RTA могут выполняться любые потоки, а не только тот исходный поток, который создал апартамент. Эта свобода от привязки к потоку делает объекты на базе RTA более гибкими и эффективными, чем объекты на основе STA, так как любой поток потенциально может сделать вызов объекта, просто войдя в RTA объекта. На момент написания этого текста еще окончательно не определились детали создания апартаментов RTA и входа в них. За подробностями вы можете обратиться к документации по SDK .
Когда поток впервые создается операционной системой как результат вызова CreateProcess или CreateThread, этому новообразованному потоку не сопоставлен ни один апартамент. Перед тем как использовать СОМ, новый поток должен войти в какой-либо апартамент путем вызова одной из приведенных далее API-функций.
В Windows NT 5.0 это будет изменено. За подробностями обращайтесь к документации по SDK.
HRESULT CoinitializeEx(void *pvReserved, DWORD dwFlags);
HRESULT Coinitialize(void *pvReserved);
HRESULT OleInitialize(vo1d *pvReserved);
Для всех трех только что описанных API-функций первый параметр зарезервирован и должен равняться нулю.
CoInitializeEx является API-функцией самого низкого уровня и позволяет вызывающему объекту определять, в какой тип апартамента нужно войти. Для того чтобы войти в МТА всего процесса, вызывающий объект должен использовать флаг COINIT_MULTITHREADED:
HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);
Для входа во вновь соаданный STA вызывающий объект должен выставить флаг COINIT_APARTMENTTHREADED:
HRESULT hr = CoInitializeEx(0, COINIT_APARTMENTTHREADED);
Каждый поток в процессе, который вызывает CoInitializeEx с применением COINIT_MULTITHREADED, выполняется в том же самом апартаменте. Каждый поток, который вызывает CoInitiаlizeEx с применением COINIT_APARTMENTTHREADED, выполняется в отдельном апартаменте, в который не могут входить никакие другие потоки. CoInitialize – это традиционная подпрограмма, которая просто вызывает CoInitializeEx с флагом COINIT_APARTMENTTHREADED. Olelnitialize сначала вызывает CoInitialize, а затем инициализирует несколько подсистем из OLE-приложений, таких как OLE Drag and Drop и OLE Clipboard. Если не предполагается использовать эти службы более высокого уровня, то в общем случае предпочтительнее использовать CoInitialize или CoInitializeEx.
Каждая из этих трех API-функций может быть вызвана больше одного раза на поток. Первый вызов каждого потока возвратит S_ОК. Последующие вызовы просто повторно войдут в тот же апартамент и возвратят S_FALSE. На каждый успешный вызов CoInitialize или CoInitializeEx из того же потока нужно вызвать CoUninitialize. На каждый успешный вызов OleInitialize из того же потока нужно вызвать OleUninitialize. Эти подпрограммы деинициализации (uninitialization) имеют очень простые сигнатуры:
void CoUninitialize(void);
void OleUninitialize(void);
Если все эти подпрограммы перед прекращением потока или процесса не вызваны, это может задержать восстановление ресурсов. Когда поток входит в апартамент, недопустимо изменять типы апартамента с использованием CoInitiаlizeEx. При попытках сделать это HRESULT будет содержать RPC_E_CHANGED_MODE. Однако, если поток полностью покинул апартамент посредством CoUninitialize, он может войти в другой апартамент путем повторного вызова CoInitializeEx.
Апартамент не является ни процессом, ни потоком; но в то же время апартаменты обладают некоторыми свойствами обоих этих понятий. Каждый процесс, использующий СОМ, имеет один апартамент или более; тем не менее, апартамент содержится ровно в одном процессе. Это означает, что каждый процесс, использующий СОМ, имеет как минимум одну группу объектов, которая удовлетворяет требованиям параллелизма и реентерабельности; однако два объекта, находящихся в одном и том же процессе, могут принадлежать к двум различным апартаментам и поэтому иметь разные ограничения по параллелизму и реентерабельности. Этот принцип позволяет библиотекам с совершенно различными понятиями о потоках мирно соучаствовать и одном общем процессе.
Поток одновременно выполняется в одном и только одном апартаменте. Для того чтобы поток мог использовать СОМ, он должен сначала войти в апартамент. Когда поток входит в апартамент, СОМ размещает информацию об апартаменте в локальной записи потока (TLS – thread local storage), и эта информация связана с потоком до тех пор, пока поток не покинет апартамент. СОМ обеспечивает доступ к объектам только для тех потоков, которые выполняются в апартаменте данного объекта. Это означает, что если поток выполняется в том же процессе, что и объект, то потоку может быть запрещено обращаться к объекту, даже если память, которую занимает объект, полностью видима и доступна. В СОМ определен HRESULT (RPC_E_WRONG_THREAD), который возвращают некоторые системные объекты при прямом обращении из других апартаментов. Объекты, определенные пользователем, также могут возвращать этот HRESULT; однако лишь немногие разработчики желают пройти столь долгий путь для обеспечения правильного использования своих объектов.
В версии СОМ под Windows NT 4.0 определяется два типа апартаментов: многопоточные апартаменты (МТА – multithreaded apartments) и однопоточные апартаменты (STA – singlethreaded apartments). В каждом процессе может быть не больше одного МТА; однако процесс может содержать несколько STA. Как следует из этих названий, в МТА может выполняться одновременно несколько потоков, а в STA – только один поток. Точнее, только один поток может когда-либо выполняться в данном STA; что означает не только то, что к объектам, находящимся в STA, никогда нельзя будет обратиться одновременно, но также и то, что только один определенный поток может когда-либо выполнять методы объекта. Эта привязка (affinity) к потоку позволяет разработчикам объекта надежно сохранять промежуточное состояние между вызовами метода в локальной памяти потока TLS (thread local storage), а также сохранять блокировки (locks), требующие поточной привязки (например, критические секции Win32 и семафоры (mutexes)).
Подобная практика приведет к катастрофе, если применять ее в случае объектов из МТА, так как в этом случае неизвестно, какой поток будет выполнять данный вызов метода. Неудобство STA заключается в том, что он позволяет одновременно выполняться только одному вызову метода, независимо от того, сколько объектов принадлежат к данному апартаменту. В случае МТА потоки могут быть распределены динамически на основании текущих запросов, вне зависимости от количества объектов в апартаменте. Для того чтобы создать параллельные серверные процессы с использованием только однопоточных апартаментов, потребуется много апартаментов, и если не соблюдать осторожность, то может возникнуть непомерное количество потоков. Кроме того, уровень параллелизма в основанных на STA обслуживающих процессах не может превышать общее число объектов в процессе. Если процесс сервера содержит только малое число крупномодульных (coarse-grained) объектов, то удастся обойтись малым числом потоков, даже если каждый объект существует в своем отдельном STA .
В будущей реализации СОМ будет, возможно, введен третий тип апартамента – апартамент, арендованный потоками (RTA – rentalthreaded apartment). Подобно МТА, RTA позволяет входить в апартамент более чем одному потоку. Но, в отличие от МТА , когда поток входит в RTA, он вызывает блокировку всего апартамента (apartment-wide lock) (то есть он как бы арендует апартамент), которая запрещает другим потокам одновременно входить в апартамент. Эта блокировка апартамента снимается, когда поток покидает RTA , что позволяет войти следующему потоку. В этом отношении RTA подобен МТА , за исключением того, что все вызовы методов осуществляются последовательно. Это обстоятельство делает RTA значительно удобнее для классов, относительно которых неизвестно, являются ли они потокобезопасными. Хотя все вызовы в STA также осуществляются сериями, объекты на основе RTA отличаются тем, что в них нет привязки потоков; то есть внутри RTA могут выполняться любые потоки, а не только тот исходный поток, который создал апартамент. Эта свобода от привязки к потоку делает объекты на базе RTA более гибкими и эффективными, чем объекты на основе STA, так как любой поток потенциально может сделать вызов объекта, просто войдя в RTA объекта. На момент написания этого текста еще окончательно не определились детали создания апартаментов RTA и входа в них. За подробностями вы можете обратиться к документации по SDK .
Когда поток впервые создается операционной системой как результат вызова CreateProcess или CreateThread, этому новообразованному потоку не сопоставлен ни один апартамент. Перед тем как использовать СОМ, новый поток должен войти в какой-либо апартамент путем вызова одной из приведенных далее API-функций.
В Windows NT 5.0 это будет изменено. За подробностями обращайтесь к документации по SDK.
HRESULT CoinitializeEx(void *pvReserved, DWORD dwFlags);
HRESULT Coinitialize(void *pvReserved);
HRESULT OleInitialize(vo1d *pvReserved);
Для всех трех только что описанных API-функций первый параметр зарезервирован и должен равняться нулю.
CoInitializeEx является API-функцией самого низкого уровня и позволяет вызывающему объекту определять, в какой тип апартамента нужно войти. Для того чтобы войти в МТА всего процесса, вызывающий объект должен использовать флаг COINIT_MULTITHREADED:
HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);
Для входа во вновь соаданный STA вызывающий объект должен выставить флаг COINIT_APARTMENTTHREADED:
HRESULT hr = CoInitializeEx(0, COINIT_APARTMENTTHREADED);
Каждый поток в процессе, который вызывает CoInitializeEx с применением COINIT_MULTITHREADED, выполняется в том же самом апартаменте. Каждый поток, который вызывает CoInitiаlizeEx с применением COINIT_APARTMENTTHREADED, выполняется в отдельном апартаменте, в который не могут входить никакие другие потоки. CoInitialize – это традиционная подпрограмма, которая просто вызывает CoInitializeEx с флагом COINIT_APARTMENTTHREADED. Olelnitialize сначала вызывает CoInitialize, а затем инициализирует несколько подсистем из OLE-приложений, таких как OLE Drag and Drop и OLE Clipboard. Если не предполагается использовать эти службы более высокого уровня, то в общем случае предпочтительнее использовать CoInitialize или CoInitializeEx.
Каждая из этих трех API-функций может быть вызвана больше одного раза на поток. Первый вызов каждого потока возвратит S_ОК. Последующие вызовы просто повторно войдут в тот же апартамент и возвратят S_FALSE. На каждый успешный вызов CoInitialize или CoInitializeEx из того же потока нужно вызвать CoUninitialize. На каждый успешный вызов OleInitialize из того же потока нужно вызвать OleUninitialize. Эти подпрограммы деинициализации (uninitialization) имеют очень простые сигнатуры:
void CoUninitialize(void);
void OleUninitialize(void);
Если все эти подпрограммы перед прекращением потока или процесса не вызваны, это может задержать восстановление ресурсов. Когда поток входит в апартамент, недопустимо изменять типы апартамента с использованием CoInitiаlizeEx. При попытках сделать это HRESULT будет содержать RPC_E_CHANGED_MODE. Однако, если поток полностью покинул апартамент посредством CoUninitialize, он может войти в другой апартамент путем повторного вызова CoInitializeEx.
Объекты, интерфейсы и апартаменты
Клиенты хотят вызывать методы объектов. Объекты просто хотят выставлять свои методы для клиентов. Тот факт, что объект может иметь ограничения на параллелизм (concurrency constraints), отличные от тех, которые привносятся клиентским апартаментом, является элементом реализации, о котором клиент не должен знать. Кроме того, если разработчик объекта сочтет нужным развернуть реализацию объекта только на малом количестве хост-машин, которое не содержит той хост-машины, где находится программа клиента, то это также является деталью реализации, о которой клиент не должен знать. В любом случае, однако, объект должен находиться в апартаменте, отличном от апартамента клиента.
С точки зрения программирования, членство в апартаменте является атрибутом интерфейсного указателя, а не атрибутом объекта. Когда интерфейсный указатель возвращается после вызова API-функции СОМ или после вызова метода, то поток, осуществивший вызов API-функции или метода, определяет, к какому апартаменту принадлежит результирующий интерфейсный указатель. Если вызов возвращает указатель на текущий объект, то объект сам расположен в апартаменте вызывающего потока. Часто объект не может находиться в вызывающем апартаменте: или потому, что объект уже существует и другом процессе или на другой хост-машине, или потому, что требования параллелизма, присущие этому объекту, несовместимы с клиентским апартаментом. В этих случаях клиент получает указатель на заместитель (proxy).
В СОМ заместителем называется объект, семантически идентичный объекту в другом апартаменте. По смыслу заместитель представляет собой точную копию объекта в другом апартаменте. Заместитель выставляет тот же набор интерфейсов, что и представляемый им объект, однако реализация заместителем каждого из интерфейсных методов просто переадресовывает вызовы на объект, обеспечивая тем самым то, что методы объекта всегда выполняются в его апартаменте. Любой интерфейсный указатель, получаемый клиентом от вызова API-функции или вызова метода, является легальным для всех потоков в апартаменте вызывающего объекта независимо от того, указывает он на объект или на заместитель.
Разработчики объектов выбирают типы апартаментов, в которых могут выполняться их объекты. В главе 6 будет рассмотрено, что внепроцессные серверы явно задают тип своих апартаментов посредством вызова CoInitializeEx с соответствующим параметром. Для внутрипроцессных серверов необходим другой подход, так как CoInitializeEx уже вызывалась клиентом во время создания объекта. Для того чтобы внутрипроцессные серверы могли контролировать тип своих апартаментов, в СОМ каждому CLSID разрешается задавать свою собственную потоковую модель (threading model), которая объявляется в локальном реестре с использованием переменной под названием ThreadingModel:
[HKCR\CLSID\ {96556310-D779-11d0-8C4F-0080C73925BA}\InprocServer32]
@="C:\racer.dll"
ThreadingModel="Free"
Каждый CLSID в DLL может иметь индивидуальную ThreadingModel. Под Windows NT 4.0 СОМ допускает четыре возможных значения ThreadingModel для CLSID . Значение ThreadingModel="Both" указывает на то, что класс может выполняться как в МТА, так и в STA. Значение ThreadingModel="Free" указывает, что класс может выполняться только в МТА. Значение ThreadingModel="Apartment" указывает, что класс может выполняться только в STA. Отсутствие ThreadingModel означает, что класс может выполняться только в главном STA. Главный STA определяется как первый STA, который должен быть инициализирован в процессе.
С точки зрения программирования, членство в апартаменте является атрибутом интерфейсного указателя, а не атрибутом объекта. Когда интерфейсный указатель возвращается после вызова API-функции СОМ или после вызова метода, то поток, осуществивший вызов API-функции или метода, определяет, к какому апартаменту принадлежит результирующий интерфейсный указатель. Если вызов возвращает указатель на текущий объект, то объект сам расположен в апартаменте вызывающего потока. Часто объект не может находиться в вызывающем апартаменте: или потому, что объект уже существует и другом процессе или на другой хост-машине, или потому, что требования параллелизма, присущие этому объекту, несовместимы с клиентским апартаментом. В этих случаях клиент получает указатель на заместитель (proxy).
В СОМ заместителем называется объект, семантически идентичный объекту в другом апартаменте. По смыслу заместитель представляет собой точную копию объекта в другом апартаменте. Заместитель выставляет тот же набор интерфейсов, что и представляемый им объект, однако реализация заместителем каждого из интерфейсных методов просто переадресовывает вызовы на объект, обеспечивая тем самым то, что методы объекта всегда выполняются в его апартаменте. Любой интерфейсный указатель, получаемый клиентом от вызова API-функции или вызова метода, является легальным для всех потоков в апартаменте вызывающего объекта независимо от того, указывает он на объект или на заместитель.
Разработчики объектов выбирают типы апартаментов, в которых могут выполняться их объекты. В главе 6 будет рассмотрено, что внепроцессные серверы явно задают тип своих апартаментов посредством вызова CoInitializeEx с соответствующим параметром. Для внутрипроцессных серверов необходим другой подход, так как CoInitializeEx уже вызывалась клиентом во время создания объекта. Для того чтобы внутрипроцессные серверы могли контролировать тип своих апартаментов, в СОМ каждому CLSID разрешается задавать свою собственную потоковую модель (threading model), которая объявляется в локальном реестре с использованием переменной под названием ThreadingModel:
[HKCR\CLSID\ {96556310-D779-11d0-8C4F-0080C73925BA}\InprocServer32]
@="C:\racer.dll"
ThreadingModel="Free"
Каждый CLSID в DLL может иметь индивидуальную ThreadingModel. Под Windows NT 4.0 СОМ допускает четыре возможных значения ThreadingModel для CLSID . Значение ThreadingModel="Both" указывает на то, что класс может выполняться как в МТА, так и в STA. Значение ThreadingModel="Free" указывает, что класс может выполняться только в МТА. Значение ThreadingModel="Apartment" указывает, что класс может выполняться только в STA. Отсутствие ThreadingModel означает, что класс может выполняться только в главном STA. Главный STA определяется как первый STA, который должен быть инициализирован в процессе.