Модели потоков. Потоки и апартаменты

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

   
Windows - многозадачная и многопоточная среда с вытесняющей многозадачностью. Применительно к СОМ это означает, что клиент и сервер могут оказаться в различных процессах или потоках приложения, а
к серверу может обращаться множество клиентов, причем в непредсказуемые моменты времени. Технология СОМ решает эту проблему введением концепции апартаментов (apartments), в которых
и выполняются СОМ-клиенты и СОМ-серверы. Апартаменты бывают одпопоточиые (Single Threaded Apartment, STA) и многопоточные (Multiple Threaded Apartment, MTA).
Напомним, чем они отличаются друг от друга.
STA

   
При создании однопоточного апартамента СОМ неявно создает окно и при вызове любого метода СОМ-сервера в этом апартаменте посылает окну сообщение при помощи функции PostMessage. Таким
образом, организуется очередь вызовов методов, и каждый из них обрабатывается только после того, как обработаны все предшествующие вызовы. Ниже перечислены основные достоинства одноиоточного апартамента.

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

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

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

  • Дополнительные (и иногда излишние) затраты на синхронизацию при вызове методов.
  • Невозможность отклика на вызов метода, пока не исполнен предыдущий. Например, если текущим является метод, требующий одну минуту на исполнение, то до его завершения СОМ-объект будет недоступен.

   
Тем не менее STA, как правило, является наиболее подходящим выбором для реализации СОМ-сервера. Использовать МТА есть смысл только в том случае, если STA не подходит для конкретного сервера.
МТА

   
Многопоточный апартамент не реализует автоматически синхронизацию и свободен от связанных с этим ограничений. Внутри него может быть создано сколько угодно потоков и объектов, причем каждый объект не
привязывается к какому-то конкретному потоку. Это означает, что любой метод объекта может быть вызван в любом из потоков МТА. В это же самое время в другом потоке может быть вызван любой другой (либо тот
же самый) метод СОМ-объекта по запросу другого клиента. СОМ автоматически ведет пул потоков внутри МТА и при вызове со стороны клиента находит свободный поток и в нем вызывает метод
нужного объекта. Таким образом, даже если выполнение метода требует длительного времени, для другого клиента он может быть вызван без задержки в другом потоке. Очевидно, что СОМ-сервер, работающий в МТА,
обладает потенциально более высоким быстродействием и доступностью для клиентов, однако он значительно сложнее в разработке, поскольку даже локальные данные объектов не защищены от одновременного доступа и требуют синхронизации.
Нейтральный апартамент

   
Для поддержки серверов СОМ+ в Windows 2000/XP добавлена еще одна модель потоков - модель нейтральных потоков (neutral-threaded model) и соответствующий тип апартамента -
нейтральный апартамент (neutral apartment). COM+ автоматически создает один такой апартамент на приложение для объектов, имеющих модель нейтральных потоков. Объекты с этой моделью
при вызове клиентом, находящимся в одном процессе с сервером, вызываются в потоке клиента. Таким образом минимизируются затраты на переключение потоков. Модель нейтральных потоков рекомендуется для компонентов
СОМ+, не имеющих пользовательского интерфейса.
Передача интерфейсов и параметров

   
Таким образом, СОМ-клиент и СОМ-сервер могут выполняться как в одном апартаменте, так и в разных, расположенных в различных процессах или даже на разных компьютерах. Встает вопрос - как же клиент
может вызывать методы сервера, если они находятся в общем случае в другом адресном пространстве? Эту работу берет на себя СОМ. Для доступа к серверу в другом апартаменте клиент должен запросить у СОМ
создание в своем апартаменте представителя, реализующего запрошенный интерфейс. Такой представитель в терминах СОМ называется прокси (proxy) и представляет собой объект,
экспортирующий запрошенный интерфейс. Одновременно СОМ создает в апартаменте сервера стаб (stub), принимающий вызовы от прокси и транслирующий их в вызовы сервера. Таким образом,
клиент в своем апартаменте может рассматривать прокси в качестве сервера и работать с ним так, как будто сервер создан в его апартаменте. В то же время сервер может рассматривать стаб как расположенного с ним в одном
апартаменте клиента. Всю работу по организации взаимодействия между прокси и стабом берет на себя СОМ. При вызове со стороны клиента прокси получает от него параметры, упаковывает их во внутреннюю
структуру и передает в апартамент сервера. Стаб получает параметры, распаковывает их и производит вызов метода сервера. Аналогично осуществляется передача параметров обратно. Эти процессы называются
маршалингом (marshalling) и демаршалингом (unmarshalling) соответственно. При этом апартаменты клиента и сервера могут иметь разные модели потоков и физически находиться
где угодно. Разумеется, такой вызов означает значительные накладные расходы по сравнению с вызовом сервера в "своем" апартаменте, однако это единственный способ обеспечить корректную работу любых клиентов и серверов.
Чтобы избежать накладных расходов, сервер надо создавать в том же апартаменте, в котором расположен клиент. Для корректного создания прокси в клиентском апартаменте СОМ требуется узнать "устройство" сервера.
Сделать это можно несколькими способами.

  • Реализовать на сервере интерфейс IMarshal и при необходимости прокси в виде библиотеки DLL, которая будет загружена на клиенте. Подробности реализации описаны в документации СОМ и MSDN.
  • Описать интерфейс на языке IDL (Interface Definition Language - язык определения интерфейсов) и при помощи компилятора MIDL корпорации Microsoft сгенерировать библиотеку DLL, реализующую прокси и стаб.
  • Сделать сервер совместимым с технологией OLE Automation. В этом случае СОМ самостоятельно создает прокси, используя описание сервера из его библиотеки типов - специального двоичного ресурса,
    описывающего СОМ-интерфейс. При этом в интерфейсе допустимы только совместимые с OLE Automation типы данных.

   
На следующем шаге мы рассмотрим инициализацию COM.



Вы можете оставить комментарий, или Трекбэк с вашего сайта.

Оставить комментарий