Как неуправляемые потоки и апартаменты СОМ приспособлены друг к другу

Неуправляемые потоки могут входить в управляемую среду извне. Например, управляемые объекты могут быть представлены “родному” коду через промежуточный уровень СОМ. Когда “родной” поток обращается к объекту, он входит в управляемую среду.

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

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

Подобно тому, как управляемые объекты могут быть представлены внешнему миру в виде объектов СОМ, так и объекты СОМ могут быть представлены управляемому миру в виде управляемых объектов. Когда управляемый поток вызывает таким образом объект СОМ, исполняющая среда ослабляет контроль над состоянием потока до тех пор, пока он не вернется в управляемую среду.

Предположим, что объект СОМ, написанный на “родном” С++, вызывает функцию Win32 API по имени WaitForSingleObject, чтобы ожидать сигнала от определенного объекта синхронизации. Затем, если управляемый поток вызовет Thread.Abort или Thread. Interrupt, чтобы разбудить поток, то его пробуждение будет отложено до момента, когда поток войдет обратно в управляемое окружение.

Другими словами, этот вызов не имеет эффекта до тех пор, пока поток выполняет неуправляемый код. Поэтому необходимо быть в некоторой мере осведомленным о механизмах синхронизации, используемых родными объектами СОМ, к которым обращается управляемый код.

И, наконец, если когда-нибудь в прошлом приходилось выполнять разработку в технологии СОМ, то должны быть знакомы понятия апартамента COM (COM apartment), а также сопровождающих их понятий прокси и заглушек1. Когда управляемый код производит вызов объекта СОМ, важно, чтобы управляемый код был настроен на вызов неуправляемого объекта СОМ либо через однопоточный апартамент (single-threaded apartment — STA), либо через многопоточный апартамент (multi-threaded apartment — МТА).

Это свойство можно установить для нового управляемого потока с помощью метода Thread. Set Ар art me ntState. Как только поток стартует, состояние апартамента блокируется. Другими словами, изменить его впоследствии нельзя.

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

В еще худших ситуациях объекты СОМ могут оказаться вообще не вызываемыми из других типов апартаментов.

Используя Thread. SetApartmentState, можно контролировать свойство СОМ-апартамента для создаваемых новых управляемых потоков. Но как насчет главного потока приложения?

Дело в том, что когда главный поток управляемого приложения запущен, уже слишком поздно устанавливать свойство состояния апартамента. Причина в том, что управляемая исполняющая среда инициализирует главный поток в состояние МТА при инициализации управляемого приложения. Если нужно изменить состояние апартамента главного потока на STA, то единственный способ сделать это заключается в декорировании метода Main атрибутом STAThreadAttribute.

Кстати, его можно также декорировать атрибутом MTAThreadAttribute, но это будет излишне, поскольку МТА является выбором CLR по умолчанию. Ниже показан пример:

1
2
3
4
5
public class EntryPoint 
{
[STAThread]
static void Main()  {
}

Если ранее приходилось работать с приложениями Windows Fbrms, особенно с теми, что генерируются мастерами Visual Studio, то, скорее всего, вы уже видели этот атрибут и недоумевали, зачем он нужен. Декорирование этим атрибутом главного потока графического пользовательского интерфейса приложения упрощает интеграцию элементов управления ActiveX в графический интерфейс, поскольку они обычно выполняются в STA.

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

И что более важно, когда управляемые объекты потребляются “родным” приложением через промежуточный уровень взаимодействия СОМ, состояние апартамента не управляет тем, в каком апартаменте находится объект с точки зрения “родного” приложения.

Со стороны “родного” приложения все управляемые объекты выглядят объектами СОМ, находящимися в МТА и интегрирующими FTM (Free Threaded Marshaller — свободный потоковый маршализатор). К тому же все потоки, созданные в пуле потоков CLR, всегда располагаются в МТА для процесса.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100