Сущность технологии СОМ. Библиотека программиста

Бокс Дональд

Часто бывает полезно сохранить маршалированные интерфейсные ссылки в центральной области, доступной для одного или более клиентов. Классическим примером этого является Таблица Исполняемых Объектов (Running Object Table), используемая некоторыми реализациями моникеров. Если бы маршалированные интерфейсные указатели должны были создаваться с использованием флага MSHLFLAGS_NORMAL, то только один клиент смог бы когда-либо демаршалировать объектную ссылку. Если предполагается, что объектную ссылку будут демаршалировать несколько клиентов, то ссылка должна маршалироваться с применением либо MSHLFLAGS_TABLESTRONG, либо MSHLFLAGS_TABLEWEAK. В обоих случаях маршалированная объектная ссылка может быть демаршалирована несколько раз.

Разница между сильным (strong)

и слабым (weak) табличными маршалингами заключается во взаимоотношениях между маршалированой объектной ссылкой и администратором заглушек. Когда маршалированная объектная ссылка создается с флагом MSHLFLAGS_TABLEWEAK, то внешний счетчик ссылок в администраторе заглушек не увеличивается. Это означает, что маршалированная объектная ссылка будет содержать нуль ссылок, и каждому администратору заместителей для получения одной или более внешних ссылок придется связываться с администратором заглушек. Маршалированная с помощью слабой таблицы ссылка не представляет сосчитанную внешнюю ссылку на администратор заглушек. Поэтому, когда последний администратор заместителей отсоединится от администратора заглушек, администратор заглушек самоуничтожится и, конечно, освободит все хранившиеся ссылки СОМ на объект. Если ни один администратор заместителей ни разу не свяжется с администратором заглушек, то последний останется жить в течение неопределенного времени. Отрицательной стороной является то, что неосвобожденная маршалированная объектная ссылка не заставляет оставаться в живых администратор заглушек или объект. Напротив, когда маршалированная объектная ссылка создана с применением флага MSHLFLAGS_TABLESTRONG , то есть с помощью сильной таблицы, то внешний счетчик ссылок увеличивается на единицу. Это означает, что маршалированная объектная ссылка представляет сосчитанную внешнюю ссылку на администратор заглушек. Как и в случае маршалинга по слабой таблице, каждому администратору заместителей понадобится связаться с администратором заглушек, чтобы получить одну или более дополнительных внешних ссылок. Поскольку маршалированная по сильной таблице ссылка представляет внешний счетчик ссылок на администратор заглушек, то при отсоединении последнего администратора заместителей от администратора заглушек он не будет самоуничтожаться и фактически продолжит хранение ссылок СОМ на объект. Отрицательная сторона маршалинга по сильной таблице заключается в том, что неосвобожденная маршалированная объектная ссылка влияет на жизненный цикл администратора заглушек или объекта. Это означает, что должен существовать какой-нибудь механизм для освобождения ссылок, хранящихся в объектной ссылке, маршалированной по сильной таблице. В СОМ предусмотрена API-функция CoReleaseMarshalData, которая информирует администратор заглушек о том, что маршалированная объектная ссылка уничтожается:

HRESULT CoReleaseMarshalData([in] IStream *pStm);

Подобно CoUnmarshalInterface, CoReleaseMarshalData принимает интерфейсный указатель IStream на маршалированную объектную ссылку. Если таблица маршалинга более не нужна, для ее аннулирования следует вызвать функцию CoReleaseMarshalData . Если по некоторым причинам нормально маршалированная объектная ссылка не будет демаршалироваться с помощью CoUnmarshalInterface , то должна вызываться также функция CoReleaseMarshalData .

Разработчики объектов могут обратиться к счетчику внешних ссылок администратора заглушек вручную, чтобы убедиться в том, что администратор заглушек продолжает жить во время критических фаз жизненного цикла объекта. В СОМ предусмотрена функция CoLockObjectExternal , которая увеличивает или уменьшает на единицу счетчик внешних ссылок администратора заглушек:

HRESULT CoLockObjectExternal([in] IUnknown *pUnkObject,

[in] BOOL bLock,

[in] BOOL bLastUnlockKillsStub);

Первый параметр CoLockObjectExternal должен указывать на действительный объект, он не может указывать на заместитель. Второй параметр, bLock, показывает, увеличивать или уменьшать на единицу счетчик внешних ссылок администратора заглушек. Третий

параметр показывает, нужно или нет уничтожать администратор заглушек, если этот вызов удаляет последнюю внешнюю ссылку. Чтобы понять, для чего необходима функция CoLockObjectExternal , рассмотрим объект, который контролирует некоторое аппаратное устройство и зарегистрирован в таблице исполняемых объектов (Running Object Table) с использованием маршалинга по слабой таблице. Пока объект осуществляет активный контроль, он хочет быть уверенным, что его администратор заглушек действительно существует, чтобы новые клиенты могли соединяться с объектом для проверки состояния устройства. Если же, однако, объект не осуществляет активный контроль, то он мог бы пожелать, чтобы администратор заглушек исчез, если нет соединенных с ним неосвобожденных заместителей. Для реализации такой функциональной возможности объект должен иметь метод, который начинает осуществлять контроль:

STDMETHODIMP Monitor::StartMonitoring(void) {

// ensure that stub manager/object stays alive

// убеждаемся, что администратор заглушек/объект остается жив

HRESULT hr = CoLockObjectExternal(this, TRUE, FALSE);

// start hardware monitoring

// начинаем контроль за аппаратным устройством

if (SUCCEEDED(hr))

hr = this->EnableHardwareProbe;

return hr; }

а также другой метод, который предписывает объекту закончить активный контроль:

STDMETHODIMP Monitor::StopMonitoring(void)

{

// stop hardware monitoring

// прекращаем контроль за устройством

this->DisableHardwareProbe;

// allow stub manager/object to die when no clients exist

// разрешаем администратору заглушек/объекту прекратить

// существование, когда нет клиентов

hr = CoLockObjectExternal(this, FALSE, TRUE);

return hr; }

Если принять, что объект был изначально маршалирован с помощью слабой таблицы маршалинга, то данный код обеспечивает жизнь администратора заглушек и объекта до тех пор, пока хотя бы один неосвобожденный заместитель или объект активно контролируют основное устройство.

Кроме предоставления разработчикам объектов возможности устанавливать счетчик внешних ссылок в администраторе заглушек, СОМ также позволяет разработчикам явно уничтожать администратор заглушек, независимо от числа неосвобожденных объектных ссылок. В СОМ предусмотрена API-функция CoDisconnectObject, которая находит администратор заглушек объекта и уничтожает его, отсоединяя все существующие в данный момент заместители:

HRESULT CoDisconnectObject(

[in] Unknown * pUnkObject,

// ptr to object

// указатель на объект

[in] DWORD dwReserved

// reserved, must be zero

// зарезервировано, должно равняться нулю

);

Подобно CoLockObjectExternal, функция CoDisconnectObject должна вызываться из процесса действующего объекта и не может быть вызвана на объект. Для того чтобы применить CoDisconnectObject к показанному выше объекту контроля за устройством, рассмотрим, что произошло бы, если бы состояние объекта было испорчено. Для предотвращения дополнительных вызовов методов объекта, которые могут возвращать ошибочные результаты, объект мог бы вызвать CoDisconnectObject , чтобы резко отсоединить все существующие заместители:

STDMETHODIMP Monitor::GetSample(/*[out]*/ SAMPLEDATA *ps) {

HRESULT hr = this->GetSampleFromProbe(ps);

if (FAILED(hr))

// probe or object may be corrupted

// образец или объект могут быть испорчены

CoDisconnectObject(this, 0);

return hr; }

Функция CoDisconnectObject используется также в случаях, когда процесс хочет отключиться, хотя один или более его объектов могут иметь неосвобожденные заместители. При явном вызове CoDisconnectObject до уничтожения любых объектов, которые могут иметь оставшиеся заместители, нет риска, что исходящие ORPC-запросы будут обслуживаться после того, как объект уже уничтожен. Если бы входящий ORPC-запрос должен был бы поступить после того, как объект уже уничтожен, но администратор заглушек еще жив, то небрежность привела бы к вызову интерфейсной заглушкой соответствующего метода из участка памяти, ранее известного как данный объект. Это вызвало бы лишние неприятности, связанные с тщетными усилиями по отладке.