Добрынин В.Ю. Технологии компонентного программирования

Подождите немного. Документ загружается.

Далее приведен стандартный алгоритм действий для построения DLL прокси/заглушки, обеспечивающих стандартный

маршалинг:

1. Открыть новый проект Win32 DLL -

PSPubInProcServer и добавить в него сгенерированные компилятором с IDL файлы:

{ PubInProcServerTypeInfo_i.c - определения GUID, упомянутых в IDL-файле,

{ PubInProcServerTypeInfo_p.c, dlldata.c - код для прокси/заглушек и макросы для саморегистрации формируемой

DLL.

2. Создать DEF-файл PSPubInProcServer.def

LIBRARY PSPubInProcServer.dll

EXPOTRS

DllGetClassObject @1 PRIVATE

DllCanUnloadNow @2 PRIVATE

DllRegisterServer @3 PRIVATE

DllUnregisterServer @4 PRIVATE

3. В диалоге Project|Settings на вкладке C/C++ в поле Preprocessor definitions добавить через запятую флажки

REGISTER_PROXY_DLL и _WIN32_DCOM. В результате в проект будет вставлен код саморегистрации.

4. В том же диалоге на вкладке Link в поле Object/library moduls добавить через пробел ссылки на библиотеки поддержки

удаленного вызова процедур rpcndr.lib, rpcns4.lib, rpcrt4.lib.

5. Откомпилировать проект и зарегистрировать построенную DLL прокси/заглушки с помощью Tools|Register Control.

В процессе саморегистрации построенной DLL прокси/заглушки она получает CLSID равный CLSID интерфейса

IPub. Под

соответствующим ключом реестре имеется раздел

InProcServer32 с параметром по умолчанию, задающим путь к построенной

DLL. Кроме того, регистрируются все три интерфейса под ключом HKEY_CLASSES_ROOT Interface. Интерфейсы регистрируются

под своими собственными идентификаторами (GUID). Для каждого имеется подраздел

NumMethods, в котором указывается число

методов интерфейса (включая наследуемые), и подраздел

ProxyStabClsid32, в котором указывается GUID для DLL

прокси/заглушки.

Теперь клиент и сервер не только запускаются в различных процессах, но и могут обмениваться друг с другом необходимыми

данными.

Говоря про маршалинг следует остановиться на вопросе передачи данных между клиентом и сервером. В случае, когда

передаются, например, массивы, необходимо следить за тем, кто выделяет

и освобождает память, сколько выделяется памяти.

Приведенные ниже примеры взяты из работы Richard Grimes, ``Marshaling Your Data: Efficient Data Transfer Techniques Using

COM and Windows 2000'', MSDN Magazine, September 2000.

Предположим, что некоторый интерфейс включает методы, описания которых на IDL приведено ниже

HRESULT PassLongs([in] ULONG ulNum,

[in, size_is(ulNum)] LONG* pArrIn);

HRESULT GetLongs([in] ULONG ulNum,

[out, size_is(ulNum)] LONG* pArrOut);

Здесь от клиента к объекту и обратно передаются массивы. Проще всего случай передачи массива от клиента к объекту. В этом

случае клиент сам выделяет память под массив и сам ее освобождает. При передаче массива от объекта к клиенту возможны два

варианта. В первом клиент заранее, до вызова метода знает размер передаваемого

массива, во втором этот размер сообщает

объект уже после вызова метода. Рассмотрим обе эти возможности.

Начнем со случая, когда клиент до вызова метода имеет информацию о размере массива. Код клиента

ULONG ulNum = 10;

LONG l[10];

hr = pArrObj->GetLongs(ulNum, l);

Код сервера

STDMETHODIMP CArrays::GetLongs( ULONG ulNum, LONG* pArr)

{

for ( ULONG x = 0; x < ulNum; x++) pArr[x] = x;

return S_OK;

}

Как все это работает. Клиент сам выделяет память под массив в виде стековой переменной. Это позволяет ему не заботится об ее

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

сервером) как на стороне клиента, так и на стороне объекта имеет информацию о размере передаваемого массива еще до возврата

из метода. Это позволяет ему выделить на стороне объекта память под этот массив и передать указатель на выделенную память

объекту (

pArr). Объект заполняет массив данными, после чего эти данные передаются по каналу клиенту. После передачи данных

маршалер сам освобождает выделенную на стороне объекта память.

Во втором случае клиент получает размер массива уже после вызова метода. На IDL описание метода выглядит следующим

образом

HRESULT GetLongsAlloc([out] ULONG* pNum,

[out, size_is(, *pNum)] LONG** ppArr);

Здесь запятая в size_is() говорит о том, что *pNum есть размер массива, УКАЗАТЕЛЬ на который есть ppArr.

В данном случае маршалер не может сам выделить память под массив на стороне объекта и, следовательно, это должен делать

объект. Но освобождать выделенную память после передачи данных должен уже маршалер, т.к. объект к этому моменту уже

завершит работу. Для выделения и освобождения памяти в данном случае следует использовать функции

CoTaskMemAlloc() и

CoTaskMemFree(), которые может вызывать и маршалер.

Код компонента

STDMETHODIMP CArrays::GetLongsAlloc( ULONG* pNum,

LONG** ppArr);

{

*pNum = 10;

*ppArr = reinterpret_cast<LONG*>(

CoTaskMemAlloc(*pNum * sizeof(LONG)));

for (ULONG x = 0; x < *pNum; x++) (*ppArr)[x] = x;

return S_OK;

}

Здесь reinterpret_cast<LONG*> используется для приведения типа указателя, возвращаемого при выделении памяти, к

указателю на

LONG. Освобождает выделенную память сам маршалер, вызывая CoTaskMemFree.

На стороне клиента память выделяет маршалер, получив информацию о размере массива -

*pNum. Освобождает же эту память

клиент

ULONG ulNum;

LONG* pl;

hr = pArrObj->GetLongsAlloc( &ulNum, &pl );

for (ULONG ul = 0; ul < ulNum; ul++)

printf("%ld\n", pl[ul]);

CoTaskMemFree(pl);

Потоковая модель и апартаменты

Процесс и поток

Прежде всего вспомним некоторые понятия, связанные с процессами и потоками.

Приложение - это один или несколько процессов.

Каждый процесс имеет ряд ресурсов, среди которых виртуальное адресное пространство процесса, исполняемый код, данные,

дескрипторы объектов, переменные среды, базовый приоритет. Таким образом, процесс это скорее среда, в которой выполняется

один или несколько потоков.

Поток - выполнение

последовательности машинных команд. Потоки, живущие в одном процессе, делят все его ресурсы. Кроме

того, каждый поток имеет и свои собственные, доступные только ему ресурсы- локальная память потока.

Операционная система делит процессорное время между потоками. Очередность получения выделенного кванта времени

определяется приоритетом потока. По завершении выделенного кванта времени система сохраняет контекст

исполняемого потока

(некоторый набор данных, хранящий состояние прерванного потока) и восстанавливает контекст очередного потока,

получающего новый квант времени.

Очередь потоков регулируется с помощью их приоритетов. Для каждого уровня приоритета имеется своя очередь. Переключение

контекста (прерывание исполняемого потока и выполнение нового) происходит при возникновении одного из трех событий:

z закончился квант времени, выделенный потоку;

z готов к выполнению поток с более высоким приоритетом;

z исполняемый поток перешел в состояние ожидания.

Базовый приоритет потока определяется двумя величинами : приоритетом процесса и приоритетом потока в рамках данного

процесса. Очередность определяется не базовым, а динамическим приоритетом.

асто динамический приоритет просто совпадает

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

приоритет.

Например, если поток выполняет операции ввода/вывода, то система может приписать ему повышенный динамический

приоритет. Однако, этот приоритет уменьшается на 1 после получения данным потоком очередного кванта процессорного

времени и может

достигнуть базового значения. Ниже базового значения приоритет не уменьшается.

Еще один пример повышенного динамического приоритета связан с тем случаем, когда некоторый поток с высоким приоритетом

ожидает завершения потока с низким приоритетом. Обычно в таком случае поток с низким приоритетом просто прерывается, но

возможны ситуации, когда выполнение потока с высоким приоритетом

остается заблокированным. Например, если поток с

низким приоритетом вошел в критическую секцию (далее будет объяснено это понятие), и в эту же критическую секцию хочет

войти поток с высоким приоритетом. Пока поток, находящийся в критической секции, не выйдет из нее, никто не сможет туда

войти. В этом случае система приписывает потоку в

критической секции высокий приоритет с тем, чтобы этот поток быстрее

завершил свою работу.

Как порождаются потоки ? Первый поток образуется при выполнении функции

main. Новый поток можно запустить функцией

CreateThread. В качестве одного из параметров этой функции передается адрес функции, которая будет выполняться в потоке.

Одна из важнейших связанных с потоками проблем - синхронизация их доступа к разделяемым данным. Это затрагивает

глобальные и статические переменные. Рассмотрим следующий сценарий. Поток A считывает значение глобальной переменной

X, после чего его выполнение прерывается. После этого поток B считывает и модифицирует значение переменной X. После

восстановления контекста потока A этот поток модифицирует переменую X, уничтожая тем

самым результат работы потока B.

Один из способов решения указанной проблемы - использование критических секций. Некоторый участок кода объявляется

критической секцией, и поток, желающий войти в эту критическую секцию (начать выполнение содержащегося в ней кода),

сообщает об этом другим потокам данного процесса. Он входит в критическую секцию только получив разрешение от всех

других

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

Дейкстра и позже улучшен Кнутом.

Следующий стандартный псевдокод иллюстрирует использование критических секций

class CoClass { public:

CoClass::CoClass()

{

InitializeCriticalSection(&m_cs);

}

CoClass::~CoClass()

{

DeleteCriticalSection(&m_cs);

}

HRESULT __stdcall CoClass::Method()

{

EnterCriticalSection(&m_cs);

..........

LeaveCriticalSection(&m_cs);

return S_OK;

}

private:

CRITICAL_Section m_cs;

};

В данном случае критическая секция охватывает целиком метод Method. Возможно, конечно, включить в критическую секцию и

небольшой участок кода.

Использование критических секций позволяет запретить параллельное выполнение некоторых участков кода. Но это не решает

всех проблем. Например, как с помощью критических секций обеспечить синхронизацию доступа к глобальной переменной

g_objCount, используемой для подсчета числа активированных экземпляров классов, определенных в сервере PubInProcServer?

Здесь удобнее применять функции

InterLockedIncrement(&g_objCount)и

InterLockedDecrement(&g_objCount), обеспечивающие безопасное увеличение и уменьшение на единицу значения параметра

функции.

Последнее, что нужно упомянуть в связи с потоками - понятие окна и очереди сообщений. В Windows все потоки делятся на два

класса: потоки с окном и рабочие потоки. В первом случае с потоком связано некоторое окно (возможно, скрытое), оконная

процедура и очередь

сообщений. Поток выбирает очередное сообщение из очереди сообщений и переправляет его в оконную

процедуру, которая и определяет способ обработки данного сообщения. Это реализуется с помощью следующего цикла

MSG msg;

while(GetMessage(&msg, 0, 0, 0))

DispatchMessage(&msg);

Во втором случае окно, оконная процедура и очередь сообщений не используются.

Потоки с окном используются прежде всего при реализации интерфейса пользователя. Однако, эти потоки играют особую роль и

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

рассчитаны на одновременный вызов их методов из различных

потоков. Подробнее об этом рассказывается в следующем разделе.

Апартаменты

COM появился до того, как в Windows появилась многопоточность. В связи с этим, в рамках одного приложения могут

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

их погрузить в среду, в которой выполняется несколько потоков, то возможны проблемы. При параллельном вызове одного и

того

же метода такого объекта возможны, например, ранее описанные ошибки модификации глобальных и статических

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

использованием критических секций. Такие объекты называются потоко-безопасными.

Апартаменты - это способ обеспечить совместную работу в рамках одного приложения объектов обоих типов. Тривиальное

решение

- запретить параллельное обращение ко всем объектам. Но это во многих случаях недопустимо. Например, система

должна быстро реагировать на ввод данных от нескольких параллельно работающих пользователей. Следовательно, необходимо

обеспечить для объекта каждого типа безопасную работу с максимально возможной производительностью.

Апартамент - это относительно сложное понятие. Но, тем не менее, следует затратить определенные

усилия на то, чтобы

разобраться в данном вопросе. Имеются экспертные оценки, в соответствии с которыми до 40 процентов ошибок при создании

систем, основанных на технологии COM, вызваны недостаточным пониманием апартаментов.

Итак, начнем с иерархии процессов, апартаментов, потоков и объектов:

z В каждом процессе имеется один или несколько апартаментов.

z Каждый поток живет в определенном апартаменте.

z Каждый объект живет в определенном апартаменте.

Имеется три типа апартаментов:

z STA (Single-Threaded Apartment)

В одном процессе может иметься несколько апартаментов этого типа. Один из них (созданный первым) носит название

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

один поток, причем это поток с окном. Именно этот поток выполняет все вызовы методов объектов, живущих в данном

апартаменте.

z MTA (MultiThreaded Apartment)

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

методов. С MTA связан пул потоков (рабочих потоков), из которого и выбирается новый поток для выполнения нового

вызова метода объекта, живущего в данном апартаменте.

z NA (Neutral apartment)

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

методов. Нет потоков, связанных с NA навечно. Любой поток из STA или MTA может временно покинуть свой апартамент

и заняться выполнением некоторого метода некоторого объекта, живущего в NA.

Теперь рассмотрим процесс создания апартаментов, связь с ними потоков и объектов. Ограничимся

случаем сервера,

исполняющегося в процессе клиента.

Потоки создаются клиентом. Клиент имеет возможность связать данный поток с STA или MTA апартаментами. При этом либо

создается новый апартамент, либо поток связывается с уже существующим апартаментом.

Если поток собирается работать с COM, он должен вызвать

CoInitialize(NULL), CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)

или

CoInitializeEx(NULL, COINIT_MULTITHREADED). В первых двух случаях создается новый STA и данный поток связывается с

этим STA. Первый из созданных STA объявляется главным. В третьем случае создается MTA, если он не был создан ранее.

Данный поток связывается с MTA.

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

идентификатор апартамента и его

тип. Связь потока с апартаментом обеспечивается тем, что идентификатор апартамента

сохраняется в локальной памяти потока (TLS - Thread Local Storage).

Создание объекта инициируется в определенном потоке, который уже приписан некоторому апартаменту. Но тип объекта,

допустимость параллельного вызова его методов не определяется при создании объекта. Эта информация задается разработчиком

класса и хранится в реестре системы.

Мы уже

знаем, что если некоторый сервер предназначен для выполнения в процессе клиента, то для каждого его класса в реестре

системы имеется раздел

InProcServer32. В этом разделе имеется параметр по умолчанию, значением которого является путь к

DLL, содержащей код данного сервера. В этом же разделе может иметься именованный параметр -

ThreadingModel. Именно этот

параметр определяет тип апартамента, в котором может жить экземпляр данного класса. В таблице 2.1 перечислены возможные

значения данного параметра и допустимые типы апартаментов.

Отметим несколько моментов, связанных с этой таблицей.

Значение

Нет соответствует случаю класса, который создавался до внедрения многопоточности в Windows. Все экземпляры таких

классов помещаются в главный STA. В связи с тем, что с этим апартаментом связан только один поток, методы всех объектов,

живущих в данном апартаменте, не могут выполняться параллельно. Это гарантирует безопасность работы с такими объектами в

многопотоковой среде. Но

эта безопасность достигается за счет неизбежного снижения производительности системы. Чем

больше объектов живет в главном STA, тем дольше приходится клиенту ожидать выполнения вызова метода живущего в этом

апартаменте объекта.

Значение

Apartment означает, что экземпляр данного класса не расчитывает на параллельный вызов его методов, хотя сам

обращается к глобальным переменным (например, счетчикам числа активированных объектов) безопасным образом. Объкт,

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

этом STA и будет жить новый объект. Если

же этот поток принадлежит MTA, то будет создан новый STA (и новый связанный с

Table: Соответствие потоковой модели

класса и допустимого типа апартамента

Потоковая модель Тип апартамента

Нет Главный STA

Apartment Любой STA

Free MTA

Both Любой STA или MTA

Neutral NA

ним поток), в который и будет помещен созданный объект. Данная модель позволяет параллельно обращаться к объектам,

живущим в различных STA. Это существенное улучшение по сравнению с использованием одного главного STA.

Значение

Free означает, что экземпляр данного класса знает о потоках все и готов к получению параллельных вызовов своих

методов. Такой объект помещается в MTA (MTA создается, если его ранее не было).

Значение

Both означает, что экземпляр данного класса не только готов к получению параллельных вызовов своих методов, но и

осторожен в обращении со своими клиентами. При взаимодействии двух объектов разделение их по признаку клиент/сервер

достаточно условно. Вызываемый объект в свою очередь может вызвать какие-то методы вызывающего объекта. Разделяя

потоко-безопасные и

потоко-опасные объекты по различным апартаментам (MTA и STA) мы обеспечиваем, кроме всего прочего,

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

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

методам. Если потоковая модель класса объявлена как

Both, это означает гарантию со стороны разработчика класса того, что

экземпляр данного класса будет корректно работать как с потоко-безопасными объектами в MTA, так и с объектами не

поддерживающими параллельный доступ, в STA. Это позволяет разместить данный объект в том апартаменте, в котором живет

создавший его поток. Тем самым обеспечивается максимальная эффективность доступа

к методам данного объекта из создавшего

его потока.

Значение

Neutral требует размещения экземпляра класса в апартаменте NA.

Таблица 2.2 суммирует сделанные выше замечания. В первом столбце указывается тип апартамента, в котором живет поток,

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

от значения параметра

ThreadingModel, приписанного соответствующему классу в реестре системы.

Итак, мы рассмотрели типы апартаментов и условия, определяющие привязку потоков к апартаментам и размещение создаваемых

объектов в апартаментах. Теперь надо разобраться с тем, как можно вызывать объекты из потоков, которые могут принадлежать

как одному, так и различным апартаментам.

Проще всего ситуация, когда и вызывающий

поток и вызываемый объект находятся в одном апартаменте, причем поток,

создавший этот объект, находится в этом же апартаменте

z В случае STA

поток имеет прямой указатель на некоторый интерфейс объекта (т.к. именно этот поток и создал этот объект) и может

делать прямые вызовы его методов.

z В случае MTA

{ либо данный поток создал данный объект

и, следовательно, имеет на него прямой указатель,

{ либо объект создан каким-то другим потоком из MTA.

В этом случае поток, создавший объект, может сохранить указатель на его интерфейс в глобальной переменной. Все

остальные потоки из MTA (и только из MTA!) могут использовать этот указатель для прямого вызова методов

данного интерфейса.

Напрямую можно обращаться и к объектам из NA, независимо от того, поток

из какого апартамента создал этот объект. Эта новая

технология появилась в Windows 2000. Рекомендуется все вновь создаваемые COM+ объекты создавать для размещения их в NA.

Преимуществом данной технологии является отсутствие переключения потоков. Вызывающий поток независимо от апартамента

покидает свой апартамент и выполняет код метода объекта из NA. В данном разделе мы более не будем обсуждать

эти новые

возможности и продолжим изучать проблемы, связанные с классическими STA и MTA.

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

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

В чем

причина? Вызов через границы апартаментов выполняется через пару прокси/стаб. Прокси находится в апартаменте

вызывающего процесса, а стаб в апартаменте вызываемого объекта.

Зачем нужны эти прокси и стаб? До сих пор они упоминались как средство, обеспечивающее маршалинг вызовов методов через

границу между процессами или между машинами. Но в данном случае

и вызывающий поток, и вызываемый объект находятся в

одном адресном пространстве. Ответ состоит в следующем. Прямой вызов через границы апартаментов запрещен, т.к. иначе

возможно параллельное обращение к объекту, который не поддерживает параллельные вызовы своих методов. Прокси и стаб

обеспечивают безопасный доступ к объекту из другого апартамента.

Здесь уместно заметить, что

прокси и стаб должны быть зарегистрированы в реестре как поддерживающие потоковую модель

Table: В каком апартаменте создается объект

Нет Apartment Free Both Neutral

STA Главный STA STA, в MTA STA, в NA

котором котором

живет поток, живет поток,

создавший создавший

объект объект

MTA Главный STA Новый STA MTA MTA NA

Both. Это позволит загружать прокси и стаб в любой апартамент. Такая регистрация выполняется автоматически, если

используется idl для описания интерфейсов и компилятор MIDL.

Прежде чем разбирать различные возможные сценарии вызова метода объекта, рассмотрим вопрос о том, как вызывающий поток

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

z Данный поток сам инициировал порождение данного объкта

В этом случае автоматически выполняется маршалинг запрошенного интерфейса, который сводится к получению

некоторого нейтрального к апартаменту представления указателя на интерфейс, передачи его в апартамент вызывающего

потока и к построению (с помощью proxy/stab DLL, которая должна быть построена для данного сервера и

зарегистрирована на данной машине) прокси

в вызывающем апартаменте и стаба в вызываемом апартаменте. Таким

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

данном апартаменте кроме вызывающего потока имеются другие потоки (случай MTA), то и эти другие потоки могут

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

z Данный поток не инициировал порождение данного объекта

В этом случае автоматический маршалинг указателя на интерфейс в апартамент потока не проводится и нужно явным

образом запросить систему выполнить такой маршалинг.

Процедура состоит из двух шагов

{ Маршализация указателя на интерфейс

Поток из апартамента, в котором живет интересующий нас объект, формирует нейтральное относительно апартамента

представление указателя на интерфейс. Для этого вызывается функция библиотеки COM

WINOLEAPI CoMarshalInterThreadInterfaceInStream(

[in] REFIID riid,

[in] LPUNKNOWN pUnk,

[out] LPSTREAM *ppStm);

В данную функцию передаются сылка на GUID интерфейса и указатель на этот интерфейс. В качестве результата

получаем указатель на доступный для обоих потоков объект-поток (stream object), который поддерживает

стандартный интерфейс

IStream и используется для временного хранения нейтрального представления указателя на

запрошенный интерфейс.

{ Демаршализация указателя на интерфейс

Теперь поток, которому нужен указатель на наш объект, должен выполнить обратную операцию - преобразовать

указатель, хранимый в объекте-потоке из нейтральной формы в форму, которую он сможет использовать для

получения доступа к объекту через границу между апартаментами. Для этого используется следующая функция

WINOLEAPI CoGetInterfaceAndReleaseStream(

[in] LPSTREAM pStm,

[in] REFIID riid,

[out] LPVOID FAR* ppv);

Выходной параметр дает указатель на желаемый интерфейс, который на самом деле является указателем на прокси,

через который поток может делать вызов через границу между апартаментами. Как и при автоматическом маршалинге

интерфейсов здесь используется proxy/stab DLL, содержащая код маршалинга для интересующего нас интерфейса.

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

вызывающий поток и вызываемый объект находятся в

одном апартаменте, но никто в данном апартаменте не имеет прямого указателя на этот объект. Такая ситуация может

возникнуть, например, когда поток из STA создает объект с потоковой моделью

Free, а потом некоторый поток из MTA желает

вызвать метод этого объекта. В этом случае никто в MTA не имеет прямого указателя на построенный объект. Только поток в

STA имеет указатель на прокси для этого объекта. Необходимо выполнить маршализацию указателя на интерфейс в STA и его

демаршализацию в MTA. Система сама обнаружит, что вызывающий поток и

вызываемый объект находятся в одном апартаменте

и вместо прокси предоставит прямой указатель на объект.

Описанный способ маршалинга указателя на интерфейс имеет определенные недостатки:

z Неоптимальность вызова объекта с потоковой моделью Both

Объект с потоковой моделью

Both столь безопасен, что может жить в апартаменте любого типа совместно с объектами

любого типа. Если, например, такой объект был создан потоком из некоторого STA апартамента, то этот объект будет

создан в этом же апартаменте. И согласно правилам COM потоки из всех других апартаментов должны обращаться к

данному объекту только через прокси. На

самом деле, они могли бы обращаться к нему, используя прямой указатель, т.к.

этот объект сможет правильно обработать все вызовы, не зависимо от апартамента, из которого они были сделаны.

Для использования прямого указателя при вызове из другого апартамента необходимо обмануть COM. Этот прием

называется Free-Threaded Marshaler (FTM). Вот его суть.

При проектировании объекта с

потоковой моделью Both нужно предусмотреть агрегацию этим объектом одного

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

интерфейс IMarshaler.

При использовании пары функций

CoMarshalInterThreadInterfaceInStream и

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

маршалируется, интерфейс

IMarshal. Если такой интерфейс не поддерживается, то используется стандартный маршалинг и

мы получаем прокси для доступа к объекту, так как было описано ранее. Если же интерфейс

IMarshal реализован в данном

объекте, то именно он определяет способ маршалинга.

Упомянутый выше агрегируемый объект реализует интерфейс IMarshal следующим образом. Прежде всего проверяется -

выполняется ли маршалинг в рамках одного процесса, или между различными процессами или машинами. В первом случае

в объект-поток записывается прямой указатель на запрашиваемый интерфейс, который и получает вызывающий поток при

демаршализации указателя на интерфейс. Во втором случае запускается стандартный процесс маршалинга указателя на

интерфейс с

формированием прокси.

Создать агрегируемый объект, реализующий

IMarshal, можно с помощью функции CoCreateFreeThreadedMarshaler.

При использовании описанного приема нужно соблюдать определенные ограничения. Объект с FTM не должен

использовать прямые указатели на другие объекты, которые не используют FTM. Причина понятна. При нарушении

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

апартамента, чья потоковая модель может отличаться от

Both. Использование этого указателя может привести к краху всего

приложения.

z При демаршализации указателя на интерфейс уничтожается объект-поток

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

несколько раз вызывать пару функций

CoMarshalInterThreadInterfaceInStream и

CoGetInterfaceAndReleaseStream. Было бы удобно иметь одно общее для всего процесса хранилище представленных в

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

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

указателя и демаршалировать его в своем апартаменте, получив соответствующий прокси.

Такая технология реализована в COM и называется Global Interface Table (GIT). В классе с GUID

CLSID_StdGlobalInterfaceTable реализован интерфейс IGlobalInterfaceTable, методы которого позволяют

зарегистрировать новый указатель на некоторый интерфейс в этой таблице, получить его из таблицы, удалить указатель из

таблицы. При этом автоматически происходит маршализация указателя на интерфейс при его регистрации в таблице и

демаршализация при получении из таблицы.

А теперь в заключении рассмотрим механизм вызова метода через границу апартамента.

Начнем с механизма вызова объекта в STA.

При вызове объекта из STA вызов, пришедший из канала, преобразуется в сообщение, которое становится в очередь сообщений,

связанную с данным STA. Поток, живущий в STA, выбирает из очереди очередное сообщение, которое через оконную процедуру

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

. Следующее сообщение

из очереди выбирается после обработки предыдущего. Тем самым обеспечивается синхронизация вызовов объектов из STA.

Тут, однако, имеется одна тонкость. При выполнении вызова объект из этого STA может вызвать некоторый метод объекта из

другого апартамента, тот из следующего и т.д. На каком-то этапе цепочка вызовов может вернуться в апартамент,

где эта цепочка

начиналась. Этот новый вызов в форме сообщения встанет в очередь, но очередь не двигается, т.к. поток, живущий в этом

апартаменте, послал вызов за пределы своего апартамента и ждет ответа.

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

одной цепочки имеют

одинаковый GUID). Когда в очередь приходит новый вызов с GUID, совпадающим с GUID выполняемого

вызова, поток выходит из состояния ожидания и начинает выполнять вновь пришедший вызов.

В случае вызова объекта из MTA все значительно проще.

Нет никаких сообщений и их очередей. Для обработки пришедшего из канала вызова из пула связанных с MTA рабочих потоков

выбирается

произвольный поток. Когда этот поток должен сделать вызов за пределы апартамента, он входит в состояние

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

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

вызова.

Технология COM+ от Microsoft

COM+ можно назвать версией COM для Windows 2000. Но, на самом деле, это не просто очередная версия некоторого продукта.

COM представляет собой модель компонентного программирования для локальных приложений. DCOM, хотя и предоставила

возможность размещения клиента и сервера на различных машинах, является той же самой COM. Но COM+ - это уже

компонентная модель для приложений, действующих на уровне предприятия. Кроме

возможности удаленного вызова, которая

уже была в COM/DCOM, данная модель расширяет традиционную COM прежде всего предоставлением важных сервисов, без

которых создание распределенного приложения является крайне трудным, если не невозможным. Эти сервисы перечислены ниже

z Обеспечивают надежность приложения:

{ Безопасность

В отличие от локального приложения, в работу с распределенным приложением вовлечены многие конечные

пользователи, которые, с точки зрения администратора системы, должны иметь различные права доступа к данному

приложению. В COM+ решаются следующие вопросы:

 Аутентификация клиента

Тот ли он, за кого себя выдает ?

 Авторизация клиента

Какие операции может выполнять данный клиент ?

 Передача полномочий

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

формированию цепочки вызовов одними объектами других объектов. В начале цепочки используются

полномочия конечного пользователя. Но чьи полномочия будут использованы далее?

{ Транзакции

Транзакции обеспечивают целостность данных в распределенной системе. Заметим, что СУБД обеспечивают

механизм транзакций, но только в рамках одной базы данных. Здесь же в одну распределенную транзакцию могут

быть вовлечены различные независимые хранилища данных.

{ Синхронизация

В COM синхронизация доступа к объектам из разных потоков осуществляется с помощью использования механизма

апартаментов. Практика программирования показывает, что редкие программисты проектируют потоко-безопасные

компоненты, которые могут жить в таких апартаментах как MTA и NA. Как правило, используется STA, и доступ ко

всем объектам, живущим в одном STA, синхронизируется самой системой посредством очереди сообщений. COM+

идет

на встречу реальным предпочтениям программистов, предлагая возможность задавать синхронизацию доступа к

объектам декларативным образом. При этом, даже объекты, живущие в MTA или NA, могут быть защищены от

параллельного обращения.

{ Очереди (асинхронная коммуникация)

В COM вызовы всех объектов синхронны. Иными словами, поток, сделавший вызов некоторого метода некоторого

объекта, продолжает работу только после получения ответа. Исключением является поток в STA, который может

выйти из состояния ожидания ответа для обработки вызова, пришедшего извне и принадлежащего к той же цепочке

вызовов, что и вызов, ответ на

который ожидается. Такая синхронная модель очевидно не сработает при временном

выходе из строя сервера, в котором живет вызываемый объект. Решением указанной проблемы является асинхронная

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

из очереди извлекается и передается для выполнения серверу тогда, когда он станет

доступным.

z Обеспечивают масштабируемость приложения:

{ Свободно связанные события

В COM+ реализуется новая по отношению к COM модель событий. Становится возможным публикация некоторой

информации одними объектами и подписка на получение этой информации другими. Сервис событий обеспечивает

необходимый механизм для реализации этой модели.

{ Пул объектов и активация по необходимости

В COM+ различают создание/удаление объекта и его активацию/деактивацию. В ряде случаев выгодно создать

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

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

активации.

{ Базы данных в памяти

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

памяти машин среднего уровня (уровень бизнес-логики в Windows DNA архитектуре).

{ Динамическое выравнивание нагрузки

При построении новых объектов на фиксированном сервере возможна ситуация, когда некоторый сервер из

имеющихся в системе перегружен, в то время как некоторые другие простаивают. Сервис динамического

выравнивания нагрузки управляет выбором сервера, на котором будет формироваться новый объект.

Все вышеперечисленные сервисы обеспечиваются COM+, но пока остался открытым вопрос о том

, как объекты получают к ним

доступ. В COM+ принят популярный сегодня подход, основанный на парадигме декларативного программирования. Разработчик

распределенного приложения программирует только бизнес-логику. Весь остальной код, обеспечивающий использование ранее

упомянутых сервисов, генерируется автоматически. Для этого достаточно только описать требования приложения и отдельных

его элементов на некотором декларативном языке. В COM+ этот

декларативный язык очень прост и сводится к заданию значений

некоторой совокупности атрибутов, приписываемых приложению в целом, входящим в приложение компонентам, их

интерфейсам и методам.

Использование декларативного подхода в данном случае имеет ряд преимуществ по сравнению с процедурным:

z Уменьшается время на разработку приложения

z Повышается надежность кода

Автоматически сгенерированный код надежнее созданного программистом, т.к. он прошел более объемное тестирование

z Уменьшается степень зависимости приложения от конкретной версии платформы (COM+)

Пока не изменена семантика, приписанная атрибутам, данное приложение будет работать со всеми последующими

версиями платформы.

Атрибуты фактически уже приписывались компонентам и приложению уже в COM. Например, каждому классу приписывался его

уникальный

CLSID, путь к серверу (DLL или EXE файлу), потоковая модель (ThreadingModel). Однако возможности реестра

ограничены, и для хранения большого числа дополнительных атрибутов, появившихся в COM+, используется дополнительная

база данных - так называемый COM+ каталог. Имеется менеджер каталога, у которого есть доступ как к реестру системы, так и к

каталогу. Разработчик и администратор получают доступ к каталогу через

утилиту Component Services, или через иерархию

предоставляемых системой объектов.

В данном курсе вопросы администрирования специально рассматриваться не будут. Используя Component Services несложно

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

в COM+ сервисов. Именно их изучению и будет посвящена основная часть данной главы.

Архитектура COM+

Начнем со структуры приложения.

Понятия приложение, класс, интерфейс, метод образуют следующую иерархию:

приложение / класс / интерфейс / метод.

Иными словами, приложение содержит один или несколько классов (компонентов), каждый класс реализует один или несколько

интерфейсов, и каждый интерфейс описывает один или несколько методов. Причем каждый класс может входить не более чем в

одно приложение.

Имеется два типа приложений : библиотечные и серверные. Библиотечное оформляется в виде DLL и загружается в адресное

пространство

клиента. Серверное также оформляется в виде DLL, но при его активации запускается суррогатный процесс

(dllhost.exe), в адресное пространство которого и загружается эта DLL. Тип приложения определяется при его создании.

Например, при использовании Component Services задается приписываемый всему приложению атрибут, задающий его тип

активации - библиотечное или серверное приложение.

Классы бывают конфигурированные и неконфигурированные. Конфигурированный класс включен

в некоторое приложение и,

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

реестре системы.

Теперь рассмотрим, как выглядит приложение во время выполнения. Все, что говорилось ранее о процессах, потоках,

апартаментах имеет место и в COM+. Но эта архитектура усложняется введением новых элементов: контекст

и активность.

Начнем с контекста. Каждый объект инкапсулирует данные и методы. Обычно говорят, что данные описывают состояние

объекта. Однако в COM+ данные, инкапсулированные в объекте, не определяют полностью состояние объекта. Эти данные

определяют только ту часть состояния объекта, которая связана с бизнес-логикой приложения. Но конфигурированный объект в

COM+ участвует также в

транзакциях и в других сложных процессах, поддерживаемых сервисами COM+. Часть состояния

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

контекстом объекта. Для сохранения контекста объекта используется так называемый объект контекста, который автоматически

формируется при активации объекта и сопровождает объект до его деактивации

. Получить доступ к объекту контекста для

заданного объекта можно вызвав из данного объекта функцию

WINOLEAPI CoGetObjectContext

(

[in] REFIID riid,

[out] LPVOID **ppv

};

Первый параметр задает GUID запрашиваемого интерфейса, реализованного объектом контекста (IID_IObectContext,

IID_IObjectContextInfo, IID_IObjectContextActivity, IID_IContextState

). Во втором параметре возвращается адрес

указателя на запрошенный интерфейс. Используя эти интерфейсы объект может не только узнать свое текущее состояние, но и

изменить его. Рассматривать данные интерфейсы здесь мы не будем, т.к. первоначально необходимо изучить сервисы, для

использования которых эти интерфейсы и разработаны.

Термин контекст используется еще в одном смысле - множество объектов, живущих в одном апартаменте и имеющих одинаковые

требования к среде выполнения. Контекст объекта определяется при его активации и зависит как от атрибутов, приписанных

соответствующему классу, так и от контекста объекта, инициировавшего активацию данного объекта (активатора). Если

активированный объект является экземпляром неконфигурированного класса, то возможны два варианта. Если активированный

объект и его активатор живут в одном апартаменте, то активированный объект помещается в контекст активатора. В противном

случае активированный объект помещается в так называемый контекст по умолчанию своего апартамента. Для объектов,

размещенных в контексте по умолчанию, недоступны никакие сервисы.

Итак, каждый объект в COM+ живет в некотором контексте. Различные контексты не

пересекаются друг с другом и не

пересекают границы апартаментов.

Понятие контекста тесно связано с понятием перехвата. Именно механизм перехвата обеспечивает учет семантики, определенной

при задании атрибутов компонента. Don Box в статье ``Windows 2000 Brings Significant Refinements to the COM(+) Programming

Model'', Microsoft System Journal, May 1999, так описывает схему перехвата

1. Компонент описывает свои требования используя атрибуты.

2. Во время создания объекта система проверяет - выполняется ли активатор (код

, вызвавший CoCreateInstance) в среде,

совместимой с конфигурацией класса ?

3. Если ответ на предыдущий вопрос положителен, то перехват не нужен, и

CoCreateInstance возвращает прямой указатель

на объект.

4. В противном случае CoCreateInstance передает управление среде, совместимой с требованиями класса, создает там объект

и возвращает прокси.

5. Этот прокси обеспечивает совместимость среды выполнения с требованиями класса, выполняя определенные действия до и

после каждого вызова метода.

Фактически понятие перехват появилось даже ранее MTS (Microsoft Transaction Server). В приведенную выше схему полностью

укладывается процесс создания нового экземпляра класса с заданной

потоковой моделью в рамках COM. Вообще, Don Box

называет принцип перехвата краеугольным камнем современного COM программирования.

В COM маршализация указателей на интерфейс требовалась при вызове через границу апартамента. В COM+ такая маршализация

требуется при вызове через границу контекста. В соответствии с принципом перехвата только в рамках одного контекста можно

использовать прямые указатели на интерфейс.

Как и

в COM маршализация и демаршализация указателей на интерфейс выполняется автоматически при создании, активации

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

интерфейс объекта из другого контекста необходимо явным образом выполнить процедуры маршализации и демаршализации

указателя на интерфейс. Для этого можно использовать функции

CoMarshalInterface и CoUnmarshalInterface. Для некоторой

оптимизации этого процесса можно проектировать объекты с FTM и использовать GIT, как это было в COM.

Синхронизация

Ранее уже упоминалаось, что при программировании в COM+ рекомендуется выбирать для новых классов потоковыю модель

ThreadingModel = Neutral. Все экземпляры такого класса будут размещаться в одном апартаменте NA. Основное преимущество

этого апартамента состоит в том, что он не имеет связанных с ним потоков, и поток из любого другого апартамента, сделавший

вызов метода объекта из NA, временно покидает свой апартамент и выполняет код вызванного метода. Отсутствие переключения

потоков существенно снижает затраты

на вызов. Однако, необходимо побеспокоиться о синхронизации. Сам апартамент NA

никак не ограничивает возможность параллельного вызова одного и того же метода одного и того же объекта из NA.

В рамках COM синхронизация обеспечивалась либо написанием потоко-безопасного кода (например, путем использования

критических секций), либо объект помещался в STA апартамент. В COM+ появляется новая возможность - декларация

необходимости

синхронизации путем задания нужного значения для соответствующего атрибута. Сама синхронизация

обеспечивается через механизм, основанный на понятии активность.

Активность - множество из нескольких контекстов, которые могут находиться не только в различных апартаментах, но и в

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

быть

контексты, не входящие ни в одну активность.

Включение контекста в некоторую активность определяется атрибутом

Synchronization входящих в контекст объектов. В

таблице 3.1 приведены возможные значения этого атрибута и их влияние на вхождение контекста, которому будет принадлежать

активируемый объект, в ту или иную активность.

При назначении значения атрибуту

Synchronization необходимо учитывать некоторые ограничения. Именно, если потоковая

модель класса

ThreadingModel=Apartment, или данный класс поддерживает активацию по необходимости, или он использует сервис

транзакций, необходимо выбрать для значения атрибута синхронизации либо

REQUIRED, либо REQUIRES_NEW.

Теперь рассмотрим собственно механизм синхронизации. На уровне процесса активность блокируется как только поступил вызов

к одному из объектов одного из ее контекстов. Только после выполнения этого вызова блокировка снимается и другой вызов

может войти в активность. Для предотвращения deadlock используется отслеживание цепочек вызовов. Каждый вызов получает

уникальный идентификатор (GUID), и все вызовы,

сделанные для выполнения этого вызова, получают тот же идентификатор.

Вызов, идентификатор которого совпадает с идентификатором вызова, блокировавшего активность, желающий войти в

активность, входит в нее.

К сожалению, описанный механизм синхронизации не решает проблему синхронизации полностью. Блокировка при вызове

объекта из некоторой активности устанавливается на уровне процесса. Это означает, что в случае

, когда активность включает

контексты из нескольких процессов, вызовы, направленные в контексты данной активности, но принадлежащие различным

процессам, могут выполняться параллельно. Это может привести к deadlock. Пример приведен в упомянутой выше статье Don

Box. Пусть поток X вызывает объект A, поток Y вызывает объект B, объекты A и B принадлежат одной активности, но разным

процессам. В этом случае вызовы могут

выполняться параллельно. Пусть теперь объект A вызвал объект B, а объект B вызвал

объект A. Возникает deadlock, так как эти вызовы принадлежат разным цепочкам вызовов и блокируют друг друга.

Рецепт следующий. Не следует различным клиентам пользоваться одними и теми же объектами-серверами. Каждый клиент

должен активировать для себя новый объект-сервер. Разделять следует только данные.

Их согласованность будет обеспечиваться

сервисом транзакций.

Рассмотрев понятие синхронизации можно поставить вопрос о роли апартаментов в COM+. Как говорит Don Box, их роль резко

ограничена. Это привязка потоков к контекстам и только. Действительно, к каждому апартаменту кроме NA привязан один (в

случае STA) или несколько (в случае MTA) потоков. Эти потоки могут вызвать любой метод любого объекта

из

соответствующего апартамента. Методы объекта из NA вообще могут быть вызваны из любого потока. Механизм синхронизации

в COM+ определяет когда поток из апартамента может вызвать метод объекта, живущего в некотором контексте этого

апартамента.

Распределенные транзакции

Table: Активность, которой будет принадлежать контекст

активируемого объекта

Значение атрибута Будет принадлежать Будет принадлежать

Synchronization какой-либо активности активатора?

для нового класса активности?

NOT_SUPPORTED Нет Нет

SUPPORTED Если активатор Если активатор

в активности в активности

REQUIRED Да Если активатор

в активности

REQUIRES_NEW Да Нет